The VSO Study group Stanford University National Solar Observatory Montana State University Solar Data AnalysisCenter Richard. S. BogartKaren Tian Frank Hill Stephen Wampler Piet Martens Alisdair Davey Joseph B. GurmanGeorge Dimitoglou Executive Summary Space-based solar physics missions such as Yohkoh, SOHO, and TRACEhave acquired or continue to amass large datasets, and the next fiveyears will see further growth as Solar-B, STEREO, and SDO data becomeavailable. Many of these datasets are mirrored, that is, served from morethan one location on the Internet, at least partly for reasons ofbandwidth. Similarly, groundbased helioseismoligy networks such asGONG+ are acquiring data at higher rates than ever before, and the SOLISsynoptic program promises to add Pbytes (1 Petabyte = 103 Terabyte = 106 Gigabyte) more. (By comparison, starting in 2007, SDO shouldproduce ~ 1 Tbyte of raw data a day.) At the same time that the volume and multiplicity of sources is growing, the technology to serve huge data volumes online, with negligible laborcosts after startup, has become commonplace. The move towarddistributed data service, the ease of setting up such services, and thelongstanding recognition that the best place for data service is where thescientific insight into the data also reside, have led many in the solarphysics community to believe that centralized data centers can bereplaced with a system of unified, networked access to distributedresources, that would better serve the needs of research solar physicists, while requiring fewer resources that could otherwise be directed towardresearch. The NASA Sun-Earth Connections 2001 Senior Review of operatingmissions and data centers funded the Solar Data Analysis Center (SDAC) to construct and deploy a prototype Virtual Solar Observatory (VSO) totest the distributed access concept. After a six-month design studycarried out by a group composed of solar physicists and data accessexperts at two universities, the National Solar Observatory, and the SDAC, and involving the community as broadly as possible, we are ready torecommend a VSO prototype architecture with the following, principalfeatures: • the ability to search all participating data sources with a commoninterface, • the use of existing data query facilities at the current data sources, • the use of industry-standard protocols such as eXtensible MarkupLanguage (XML) in its internals, • access through a Web browser interface to a remote VSO server, anApplication Programming Interface (API), or via a VSO instance on a local computer, and • extensibility to multiple additional features, including the registrationof searches to enable other solar physicists to, for instance, attempt toreproduce the results of published literature. In accordance with the funding profile recommended by the 2001 SECSenior Review, we propose, after a community comment period extendinginto 2003 January, to proceed with the development and deployment of aVSO prototype involving data served at four institutions (Stanford, Montana State, NSO, and the SDAC) in Fiscal Year 2003, and to improveand extend the VSO in FY 2004. That extension will take the form of assistance to smaller data providers in the form of programming advice, assistance in procuring network-attached storage, and aid inconstructing inexpensive databases, in order to allow inclusion of thosesites in the VSO. I. Introduction: Why Do We Need a VSO? The number of online sources of large amounts of solar data is increasingsteadily, and the volumes of most of the new sources due to becomeavailable over the next five years will be significantly larger than the sizeof those currently available. By 2007, we will have to confront SolarDynamics Observatory experiment archives that will grow by over a Tbytea day when decompressed. Not only is it becoming harder to determinethe Web locations of all the servers and understand the different querybuilding tools, but there is no longer a compelling reason to concentrateall the data for even a single, multiple-instrument mission in a singlephysical location. At the same time, the technologies for serving such quantities of dataonline are becoming inexpensive and simple to deploy (network attachedstorage, open source SQL databases, &c.), and no unique informationtechnology (IT) expertise is required to implement such devices ormethods. The TRACE and, more recently, RHESSI experience have shownthat implementing rapid, online access to the entire mission scientificdata set, virtually from the day of launch, is well within the reach of PIteam members. Thus, both the scale of the data access soon to face thesolar physics community and the technology argue in favor of a virtualaccess point to physically distributed data services. The ability of such a“Virtual Solar Observatory” (VSO) to simplify the diverse query schemes ofdifferent service sites must be seen as another strong argument forimplementing a VSO. The 2001 Senior Review of NASA Sun-Earth Connections (SEC) OperatingMissions and Data Centers approved additional funding for the Solar DataAnalysis Center (SDAC), in essence, to put itself out of business bybuilding and implementing a VSO. II. The Strawman VSO Concept We propose here an architecture and feature set for a prototype VSO. the prototype will not include all the features that might eventually becomepart of the VSO, nor even all the features that are concurrently underdevelopment elsewhere that should become parts of the VSO’sfunctionality. It is possible to approach the design of such a system in atleast two different ways. In one (top-down), all possible features and usesof a system are studied, and the best solution for as many as possible isproposed. This is the approach taken by the European Grid of SolarObservations (EGSO); see section V. Alternately, one can approach asystem design from the bottom up, and ask what the essential element orelements of the design have to be in order to have a functioning anduseful system. The VSO study group decided, after examining different approaches toabstracting the procedures for solar data identification and access, tobuild the “smallest box” possible around that problem, rather thanattempting to draw a box around all possible aspects of a VSO. Despitethe difference in approaches, it currently appears likely that the EGSOdesign will converge on an approach with many components in commonwith our “small box.” It is also critical to note that the VSO will not be “complete” during itsprototype stage, and even if adopted by the solar physics community, willonly become truly useful if there are adequately funded, peer-reviewedopportunities to add functionality, e.g. in the form of user interfaces, remote processing to reduce data transfer, event and feature lists, methods of connecting the VSO with other SEC-related data systems, andso on. Features of the prototype We propose to proceed with the development of a prototype VSO inFY2003, and in FY2004 add both more data services and morefunctionality. At each step in the development of the VSO, we will insurethe solar physics community a voice in the structure and direction of the VSO. A protoype VSO will offer: • virtualization of data search, data discovery, and query refinement, • multiple interfaces (browsers, application programming interface), • leveraging of existing data services (rather than creating e.g. new metadata standards), • direct user access to data (without the VSO as an intermediary), and • the ability to expand to several more data sources in theimplementation and maintenance phases of the VSO (FY04 andbeyond). A solar physicist should be able to use the VSO via a browser interface to search for data applicable to a problem he or she wishes to study; refinethe search criteria interactively through the VSO; and then retrieve thedata directly from the data source (rather than generating twice as muchnetwork traffic by having the VSO act as an intermediary for the data aswell as for the query). Alternately, one could use a an applicationprogramming interface (API) to search for (for example) the most recentimage of a given type, regardless of observatory or instrument, to updateone’s own Web site, without a user interface. The prototype VSO would start with data served by the NSO (includingGONG, GONG+, and SOLIS), the SDAC (including a variety of spacemission and ancillary data), Stanford University (including Wilcox SolarObservatory, SOHO MDI, and other helioseismic data sources), andMontana State University (including an extensive Yohkoh database). (Thedatasets at these data services are listed in Appendix C.) The prototype VSO proposed here will not include: • a central catalog, • grid computing, or • any features that limit or restrict access to data or software(authentication). The study group found that the sites most likely to be involved in theinitial stage of a prototype (i.e., those at their own institutions) alreadyoffered sophisticated query engines; there was no need to design a newone. Features that we hope could be added soon after the prototype isoperational include: • catalog caching (to speed queries), • multiple instances of the VSO (to make the VSO truly virtual, it couldrun on local machines instead of on a small number of remote servers), and • logging of searches (without identifying the party who carried out theoriginal search). We believe that multiple instantiation is a feature that many users woulddesire; the only “cost” associated with it should be the requirement totransmit logging information to one of the “primary” servers, so thefunding agency can know how extensively the VSO is being employed, and so the searches could be logged. Logged searches, identified only by date and time, could be cited in theacknowledgments of articles published using the data, and would therebyallow reproduction of results, a sound practice currently largely in disusein solar physics. Logged searches would also enable interestedresearchers to try different analysis methods on the same data sets. Figure 1. Conceptual diagram of the proposed prototype VSO. As in all virtual observatory concepts, a broker facility mediates betweenthe data user (right) and the data services (left). In this design, however, only queries and query results pass through the broker; theactual data transfer occurs outside the VSO, thus significantlyreducing network data traffic. User-initiated actions (initial query of the VSO, eventual data request) are in blue; VSO communications are in green; and the final datatransfer is in charcoal. The user initiates a query via either a browser interface, which communicates with the VSO API or directly throughthe VSO API. The query is then routed to a query construction enginewhich uses the XML schemata describing the data services todetermine the service(s) to which to route queries in formats native tothem. The query results from the data services are routed by thequery result engine back to the API or browser; the user or the user’ssoftware then decides whether to request the data from the dataservice(s). (The user’s desktop is drawn in such a way as to beplatform-agnostic.) While the prototype will probably include onlythe four named data services, more could be added at any timethereafter. VSO expansion The VSO will be fully useful only if it can be expanded beyond theprototype stage, both in the number and variety of data servicesaccessible via the VSO and in the functionality offered. The “maintenance” level of funding for the VSO proposed in the SDAC’s “outyear” (FY2004 and FY2005) budget in the 2001 Senior Review includedfunds for roughly one programmer full-time equivalent (FTE). At least50% of that effort would be available to offer advice (e.g. on the transfer of tapes-on-a-wall archives to network-accessible media), thedeployment of inexpensive network-attached storage (NAS) hardware, thedevelopment of MySQL templates for constructing databases, and alimited amount of travel to new data source sites for short periods tohelp with such VSO deployment. Extension of the capabilities of the VSO must, therefore, depend onresearch opportunities to provide, for instance: • feature and event lists, • remote processing capabilities to reduce transferred data volume (e.g. automated selection based on the presence or absence of features orevents in the data), or even • scheduling of observations when no data can be found in existing dataservices, if automatically queued observations are available. Such expansion of functionality must be funded separately from VSOdevelopment and maintenance, since it must involve the user communityand is properly a research effort. If the community believes that such aneffort is worthwhile, it should make its needs known to the fundingagencies to that new or existing programs (e.g. NASA LWS TR&T, NSFdata infrastructure); preliminary indications are that the funding agenciesare receptive to focusing some of their research opportunities on suchactivities. For more information See the VSO Website: http://virtualsolar.org/ . III. Technical Approach Motivation The data providers and sources are geographically distributed across thecountry. Almost all of the providers make their data available on theWorld-Wide Web. The access facilities vary from sophisticated, Webenabled databases to simple file systems available via FTP. Thecorresponding metadata descriptions (catalogs) maintain a similar rangeof sophistication ranging from on-line searchable databases to text (i.e. ASCII, HTML) files. A requirement for a successful VSO is the provision of a transparent viewof and access to all these datasets. Combining all of the datasets, or their catalogs, in a central repositorymay appear to be a valid approach, but it is unrealistic. Such anarchitecture simply would not scale to accommodate the ever-growingvolume and complexity of data (particularly from space-based missionsand ground-based helioseismology networks), even if synchronizing andupdating the metadata proved practicable. At the very least, it wouldrequire an additional layer of data expertise for each data service, something a small research community can ill afford. Since each dataprovider already has a network-based access method, we propose toleverage those existing (and presumably evolving) investments in querycapability to construct a VSO that presents the user with a uniforminterface for a broad selection of data services. We introduce the notion of VSO as a processing engine rather than a“database of databases.” The design presented here is lightweight, distributed, and maintains only descriptions of the data holdings andaccess methods for each data provider. The Prototype Overview We view the function of the VSO as a metadata intermediary betweenend-users and data providers. The VSO will consist of three major components: • Query Construction Engine • VSO Registry • Query Results Engine We also discuss briefly the front (user interface) and back ends; throughout, refer to Figure 1. Front end: How will I be able to use the VSO? Users will be able to access the VSO either by using a pre-defined, HTMLbased Web form or by developing a program that communicates with theVSO directly. The VSO will feature a standard Application Program Interface (API) topermit any program to build and submit queries to the QueryConstruction engine. As a result, the VSO provides the flexibility to usersto develop their own custom User Interfaces (UI’s). Query Construction Engine The Query Construction Engine is a program that receives input from auser interface and constructs a valid query using the informationstored within the Schemata Repository. The function of the Query Construction Engine is to translate the genericsearch descriptions (from user input) to data service-specific queryparameters. This involves locating the candidate data service(s) andrefining the search. As each data provider has described its data holdingto the VSO in the registry, (e.g., observable and time range information), the VSO will select one or more candidate data services whose descriptions match the generic search criteria. Once the candidate dataservices are selected, data service-specific questions can be formulatedto aid the user in refining the search. VSO Registry The VSO Registry (see Figure 1) maintains a collection of schemata andtheir instances. Each schema describes the organization of the data at a provider’s site while the instance of the schema provides the descriptions of the contents and access methods (data volumes, location) of the dataprovider. The XML Schemata are not copies of the catalog contents ofdata providers but provide templates for an XML description of theirdatasets. Back end: Query Execution Query execution and data export are the two types of services that dataservices are expected to provide to the VSO. We don't expectparticipating data services to do anything significantly different fromwhat they are already offering, i.e., allowing searches for a dataset andexporting it if requested. To participate in the VSO, each participatingdata service needs only to provide two kinds of interfaces: one to acceptquery parameters and carry out queries, and another to handle dataexport requests. Query Result Engine The function of query result is to merge the query results from multipledata services. The engine will, in so far as possible, hide theidiosyncrasies of each data service's exporting methods, and provide anintegrated view to the user. Information such as the size of the datasetare likely to be of interest to the user, and will be presented at this point. Technology Why XML? XML (eXtensible Markup Language) provides a mechanism to identifystructures in a document. It is text-based and platform-independent. Inaddition to assigning meanings to contents via user-defined XML tags(reminiscent of the "keyword=value" approach), XML can identify thestructural relationship among tags (e.g., the hierarchical structure of adocument), therefore creating a structured document. It is this feature of"structured content" that make XML attractive to us. Because of its popularity, we can leverage many existing technologies to process XMLdocuments. We will employ the capabilities of XML for both describing the dataservices and for a “Web services” approach to integrating the data servicedescription, query, and response functions of the VSO. How we will use XML i. Data Service Description To facilitate the integration of distributed data services (we distinguishbetween “data service” and “data provider,” since each provider might infact host more than one data service, with a unique access method andorganization), each data service must first be able to describe its dataholdings to the VSO. We choose XML as a “universal language” with whicheach data service “communicates” with the VSO. The VSO registry collectsthese descriptions, and serves as a resource discovery mechanism for theQuery Construction Engine. Since there's no predefined meanings for XML tags, there isn't anypreconceived semantics. We ourselves have to define the semantics of anXML document. The burden of the design therefore falls on the abstractmeta-data model that characterizes the data services of participatingdata providers. This meta-data model is implemented as an XML Schemawhich in turn specifies the structure and datatype of XML documents. The challenge is to create a meta-data model that is extensible, so that itcan support dynamically changing requirements, as data providers andservices are added and evolve. For example, in our dataset model, two basic elements are "observable" and "time range". The possible values of observables can be enforcedusing the following enumeration structure in an XML schema: ... The specification of time range is more interesting because there is morethan one way to do it, e.g. defining the start and end of the time range isone way, and the center and extent another. For non-continuousobservations, sampling rates are also needed. This is a typical example ofinheritance in the object-oriented paradigm, and can be implementedusing the abstract/substitutionGroup definition in XML schema. Spatiallocation is another element with comparable complexity and commoninheritance. ii. Service Integration WS (Web Service) augments the service methods of the Web, namelyPOST, GET, and PUT. It builds upon the platform of XML and HTTP, andincludes elements such as remote invocation (SOAP), servicecharacteristics (WSDL), and directory service (UDDI). SOAP (Simple Object Access Protocol) defines an RPC (Remote ProcedureCall) mechanism. It employs HTTP as its transport and encodes theclient-server interactions (i.e., request and response messages) in XMLdocuments. WSDL (Web Services Description Language, as its name suggests, describes what a Web service can do, where it resides, and how to invokeit. According to this information, one should be able to construct an APIto access the Web service. We are interested in the Web Service model because it provides analternative to the standard POST and GET methods. New ideas The architecture of the VSO offers some new computing ideas. First, it is not a monolithic server with a database that stores metadata. Instead, it is an agile, lightweight application program that accepts input(user queries) and provides output (data location and access). We storeXML descriptions of data providers as a data structure (it can reside inmemory) instead of static files or records. Second, we treat each user input and query not only as a transaction butas a real-time computation. By doing so, we are able view VSO's innerparts as instantiated objects and perform operations or manipulate themby applying methods. Finally, the deployment of VSO may be fully distributed with the ability tohave multiple, fully customizable VSO's running on user desktops. What a user would need to access the VSO For the prototype version we will develop at least one browser interface, an HTML-based form that would allow a user to enter search criteria. The form will communicate via the VSO API, construct a query, send it to theappropriate data providers, and finally display the results. The user couldrefine queries iteratively to produce a final result, which would allow thedirect download of data (or the queuing of larger requests) without thefinal request or fulfillment passing through the VSO itself. This type of access will probably be the most typical kind of access. However VSO is not bound to only one User Interface (UI). Users are ableto create their very own interface (web-based, command based) as longas they communicate properly with the VSO API. The VSO API will be generic enough and accessible via a least common denominator protocol(TCP/IP) allowing users to develop interfaces with any programminglanguage that supports network connectivity (e.g. C, C++, Java, Perl, Python, the IDL SolarSoft tree, and IRAF). This would allow users tointegrate an interface to the VSO into local data analysis or Websitepopulation software. IV. Programmatics Funding for the first six months of the VSO effort became available inmid-fiscal year (FY) 2002. Unsolicited proposals to perform the studytogether were received from three groups (see below), and this approachwas approved by the VSO steering committee (see appendix A). The threestudy grantee groups and the SDAC became, informally, the VSO StudyGroup (See Table 1.) Work began in early May, 2002 and continued withfortnightly telecons, one group meeting (in October, 2002), and variousoffline contacts among study group members. In addition to their design work, members of the VSO Study Grouppresented their then-current ideas of what a VSO might look like atseveral community and committee meetings (see Appendix B). SDAC Joe Gurman George DimitoglouStanford University Rick BogartKaren Tian National Solar Observatory Frank Hill Steve WamplerMontana State University Piet Martens Alisdair Davey Table 1. The VSO Study Group The work of the Study Group is now complete, with the production anddissemination of this report. Study Group members will participate in theVSO Birds of a Feather (BoF) session at the Fall AGU meeting; they havealready discussed VSO goals and designs to as much of the solar physicsand related communities as possible (see Appendix B). Management The SDAC Facility Scientist (Joe Gurman) is the de facto projectmanager/project scientist for the VSO. Charles Holmes at NASAHeadquarters is the de facto program manager, in his role as MissionOperations and Data Analysis (MO&DA) manager for solar andheliospheric physics within the Office of Space Science. Future effort If the community approves the proposed direction of the VSO effort, wewould proceed to: 1. develop and implement the prototype VSO beginning in FY2003(since NASA contracting is a somewhat sluggish process, weexpect the effort to begin no earlier than the mid-secondquarter of calendar year 2003); 2. add features to VSO in FY2004, including both in-house (e.g. multiple instantiation, catalog caching, and/or search logging) and “research opportunity” features; and 3. maintain and expand the VSO in FY2004 and beyond, dependingon funding. Budget The current budget of the VSO is shown in Table Budget-1. US Government Fiscal Year (FY) US$K 2002 160 2003 450 2004 453 2005 160 Total (approved by2002 Senior Review) 1223 Table Budget–1. Community input It is clearly in the interest of the solar physics community, as well asmembers of related discipline communities in the Sun-Earth Connectionsarea, to express their opinions about the design and direction of the VSO. They may do so, at any time, to the members of the VSO study group (see above) and to the members of the VSO steering committee, whosecurrent membership is detailed in Appendix A. In the absence of widercommunity involvement, the VSO steering committee must act in thecommunity’s interest to oversee the direction of the VSO. V. Relation to other efforts EGSO The VSO is not the only current effort attempting to construct a virtualsolar observatory. The European Grid of Solar Observations (EGSO), aneffort funded by the European Commission, is taking a more highlystructured approach, with formal Work Packages and (currently at least) amore ambitious set of design goals. Two of the VSO study group memberinstitutions (NSO and the SDAC) are unfunded US partners in the EGSOeffort. The design of the EGSO is still under discussion, but we can foreseeEGSO-VSO design issues falling into either of two scenarios: 1. similar designs 2. disparate designs In the similar design case, interfacing the VSO and EGSO should bestraightforward, and involve little cost or effort to the VSO. In thedisparate design case (one possibility under study, for instance, wouldfeature a central catalog of data), the US EGSO partners would supplytheir part of the work required (from resources other than VSO funds), and the international solar physics community would have the benefit oftwo competing architectures between which to choose. Since we believethat competition is at least as good in the marketplace of ideas as it is inthe commercial one, we welcome the latter scenario, since we lay noclaim to precognition. We can live with the former scenario, too — as longas the solar physics community remains involved in critiquing the VSOdesign and implementation. See: http://www.egso.org/ for more information. LWS Data Enviroment There is, of course, a broader effort under way to provide a dataenvironment for NASA’s Living With a Star program (and hopefully theInternational LWS program, iLWS, as well). Ideally, the VSO should “plugand play” with such a system. If the VSO proves useful to the solarphysics community, we would foresee the integration of the VSO into a anLWS data system in a way that maintains its usefulness to the base community, but broadens its functionality in such a way that non-solarphysicists would find it of use as well. We believe that such efforts mustfollow the successful development and development of the VSO. National Virtual Observatory Much better known and funded than the VSO, the NVO (and its superset, the International Virtual Observatory Association (IVOA)), seeks to offervirtualized access to a large range of astronomical databases, datamining, and other features of interest to “nighttime” astronomers. Therehave been frequent questions and feelers as to the relationship of theVSO to these efforts; the response of the study group has so far been thatwhile we are interested in any technology developed by the NVO efforts, the problem we are addressing is sufficiently different that we would rather have at least a working prototype before entering into any formaldiscussions with the “dark side.” We are simply too small (~ 60 timessmaller budget) and too different an effort to risk being subsumed intosomething as different as the NVO effort. The difference in fundingsources (NSF for the NVO, NASA for the VSO) is another distinction thatleads us to believe that for the short term, the VSO and NVO shouldremain separate entities, while we share technology and insights. See: http://us-vo.org/ for more information on the NVO. Appendices 18 A. The VSO Steering Committee Member Affiliation Robert Bentley (chair) Mullard Space Science LaboratoryUniversity College LondonSamuel Freeland Lockheed Martin CorporationAdvanced Technology CenterJ. Todd Hoeksema NASA Headquarters, Code Sand Stanford UniversityStephen R. Walton California State University, NorthridgeDepartment of Physics and AstronomyDominic Zarro L-3 Communications Analytics Corp. B. Community exposure VSO-related presentations have been given at each of the following: • American Astronomical Society meeting (Washington DC), 2002January (invited talk) • American Astronomical Society Solar Physics Division meeting(Albuquerue NM), 2002 June (poster; BoF session) • European Grid of Solar Observations (EGSO) meeting, 2002 October(presentation) • NASA Sun-Earth Connections Data and Computation Working Group(SECDCWG, Washington DC), 2002 October (presentation) • NASA Living With a Star (LWS) workshop (Scaggsville MD), 2002November (poster) • American Geophysical Union Fall meeting (San Francisco CA), 2002December (BoF) C. A sample data service schema The example below is a preliminary and highly imperfect descriptionof the holdings of the National Solar Observatory’s Digital Library. It isnot meant to represent precisely the eventual NSO data serviceschema for the VSO, but instead, what a generic schema of the typefor the proposed VSO prototype might look like. NSO-VSO Data Description This Schema defines the National Solar Observatory data holdings for theVirtual Solar Observatory. 24 D. Data services for the initial implementation of theVSO prototype Data service Data served National Solar Observatory (NSO) spectral atlasesmagnetograms (photospheric andchromospheric) Dopplergramssynoptic maps (magnetic field and otherparameters) coronal emission-line scans Synoptic Optical Long-term Investigation ofthe Sun (SOLIS; from 2004) Global Oscillations Network Group (GONG) and GONG+ Solar Data AnalysisCenter (SDAC) SOHO (except MDI high-rate) TRACE Yohkoh CGROBATSE solar flare data GOES soft X-ray photometrySMM OSO-7 raster imagesSolar-B (from 2005) STEREO (from 2005) Stanford University solargroup SOHO MDI (including high-rate) Wilcox Solar Observatory magnetogramsGONG subsets TON helioseismology databaseMt. Wilson 60-ft. tower data LOWL helioseismology databaseMontana State Universitysolar group Yohkoh database E. XML References 1.http://www.w3.org/XML/ 2.http://www.w3.org/TR/xmlschema-1/ 3.http://www.w3.org/TR/NOTE-xml-schema-req 4.http://www.xml.com/pub/a/98/10/guide0.html 5.http://www.brics.dk/~amoeller/XML/overview.html 6.http://www.xfront.com/BestPracticesHomepage.html 7.http://www.w3.org/TR/wsdl 8.http://www.uddi.org/about.html