juddi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From svi...@apache.org
Subject cvs commit: ws-juddi/site/src/documentation/content/xdocs install.xml
Date Tue, 06 Apr 2004 00:34:31 GMT
sviens      2004/04/05 17:34:31

  Modified:    site/src/documentation/content/xdocs install.xml
  Log:
  Moved installation instructions from jUDDI.org and performed some editing/updating.
  
  Revision  Changes    Path
  1.4       +142 -2    ws-juddi/site/src/documentation/content/xdocs/install.xml
  
  Index: install.xml
  ===================================================================
  RCS file: /home/cvs/ws-juddi/site/src/documentation/content/xdocs/install.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- install.xml	4 Mar 2004 20:41:12 -0000	1.3
  +++ install.xml	6 Apr 2004 00:34:31 -0000	1.4
  @@ -6,9 +6,149 @@
     </header>
     <body>
       <section>
  -      <title>Installation Guide</title>
  +      <title>Requirements</title>
  +      <p>jUDDI is a pure Java web application and as such can be deployed to 
  +        any application server or servlet engine that supports version 2.1 or 
  +        later of the servlet API. If you need an application server, we 
  +        recommend <link href="http://jakarta.apache.org/tomcat/">Jakarta 
  +        Tomcat</link>.  Note also that jUDDI requires Java 1.3 or later. As 
  +        with any Java web application, deployment to your application server 
  +        or servlet engine will vary on a product-by-product basis. 
  +		 </p>
  +      <p>Instructions for deploying jUDDI to several application servers have 
  +        been donated and are available in the <link href="/howto">HOWTO</link>

  +        section of the jUDDI documentation.
  +			</p>			
  +      <p>jUDDI also requires an external datastore in which to save and search
  +        for published web services data. Database schemas for several 
  +        different relational database are included with the jUDDI release. 
  +        Again, instructions describing how to create a jUDDI datastore using
  +        several different database servers are available in the 
  +        <link href="/howto">HOWTO</link> section of the jUDDI documentation.

  +			</p>			
  +    </section>
  +    
  +    <section>
  +      <title>Configuration</title>
  +      <p>To properly configure and deploy jUDDI it will be helpful to understand
  +        a bit about it's architecture. jUDDI consist of a core request processor
  +        that unmarshalls incoming UDDI requests, invoking the appropriate UDDI
  +        function and marshalling UDDI responses (marshalling and unmarshalling
  +        is the process of converting XML data to/from Java objects).
  +      </p>
  +      <p>To invoke a UDDI function jUDDI employs the services of three 
  +        configurable sub-components or modules that handle persistence (the 
  +        DataStore), authentication (the Authenticator) and the generation of 
  +        UUID's (the UUIDGen). jUDDI is bundled and pre-configured to use 
  +        default implementations of each of these modules to help you get 
  +        jUDDI up and running quickly. The module categories and a 
  +        description of the default implementations are described below.
  +      </p>
  +      <p>Several public Java interfaces for creating your own DataStore, 
  +        Authenticator and UUIDGen module implementations are available. Please 
  +        see the <link href="/devguide.html">jUDDI Developer's Guide</link>
for 
  +        more information regarding jUDDI module development.
  +      </p>
  +    </section>
  +
  +    <section>
  +      <title>Persistence (jUDDI DataStore)</title>
  +      <p>The default jUDDI DataStore is implemented using JDBC and the process 
  +        of setting this up is fairly straight forward. Start by creating a new 
  +        jUDDI database using one of the following database schemas.
  +      </p>
         <p>
  +        <link href="dbscripts/juddi_mysql.ddl">MySQL</link> 
  +        <link href="dbscripts/juddi_db2.ddl">DB2</link>
  +        <link href="dbscripts/juddi_hsql.ddl">HSQL</link>
  +        <link href="dbscripts/juddi_ase.ddl">Sybase</link> 
  +        <link href="dbscripts/juddi_postresql.ddl">PostreSQL</link>
  +        <link href="dbscripts/juddi_oracle.ddl">Oracle</link>
  +        <link href="dbscripts/juddi_totalxml.ddl">TotalXML</link>
  +        <link href="dbscripts/juddi_jds.ddl">JDataStore</link> (Borland)
  +      </p>
  +      <p>If a schema for your DBMS is not listed, one simply hasn't been 
  +        created yet. You can use the available schemas as a guide for 
  +        creating one (and if you're feeling generous please consider 
  +        contributing it).
  +      </p>
  +      <p>To complete the DataStore set up you'll need to configure a JNDI 
  +        Datasource named 'jdbc/juddiDB' in the application server or servlet 
  +        engine that you're deploying to. Datasource setup varies on an 
  +        product-by-product basis so review documentation for your application 
  +        server. If you're deploying jUDDI to Jakarta Tomcat, take a look at 
  +        the JNDI Datasource HOW-TO for assistance.
  +      </p>
  +    </section>
  +
  +    <section>
  +      <title>Authentication (jUDDI Authenticator)</title>
  +      <p>Authenticating a jUDDI publisher is a two-step process. The first step 
  +        confirms that the ID/password combination provided by the user is valid. 
  +        It is expected that a typical jUDDI deployment will use an external 
  +        authentication mechanism. The default authentication module simply 
  +        approves any authentication attempt. It is our hope that additional 
  +        jUDDI authentication implementations will be developed by jUDDI users 
  +        as they determine how they would like authentication to take place in 
  +        their particular environment. See the jUDDI Developers Guide for more 
  +        information on developing a custom jUDDI authentication module.
  +      </p>
  +      <p>The second step confirms that the publisher has been defined to 
  +        jUDDI. A publisher is said to be defined when a row identifying the 
  +        publisher exists in the PUBLISHER table of the jUDDI datastore. At the 
  +        moment the only way to do this is via SQL. An example of defining a 
  +        new publisher named John Doe would look like this:
  +      </p>
  +      <p>
  +         INSERT INTO PUBLISHER (PUBLISHER_ID,PUBLISHER_NAME,ADMIN,ENABLED)
  +         VALUES ('jdoe','John Doe','false','true');
  +      </p>
  +      <p>The PUBLISHER table consists of several columns but only four of them
  +        are required and they are defined as follows:
  +      </p>
  +      <p>
  +         Column Name Description 
  +         PUBLISHER_ID The user ID the publisher uses when authenticating. IMPORTANT: This
should be the same value used to authenticate with the external authentication service.  
  +         PUBLISHER_NAME The publisher's name (or in UDDI speak the Authorized Name). 
  +         ADMIN Indicate if the publisher has administrative privileges. Valid values for
this column are 'true' or 'false'. The ADMIN value is currently not used. 
  +         ENABLED Indicate if the publishers account is enabled and eligible for use. 
  +      </p>
  +      <p>The jUDDI web application will (eventually) be extended to facilitate 
  +        the Publisher creation process. The value of the ADMIN column in the 
  +        PUBLISHER table above will be used to determine who has the privilege 
  +        to create new jUDDI publishers.
  +      </p>
  +    </section>
  +
  +    <section>
  +      <title>UUID Generation (jUDDI UUIDGen)</title>
  +      <p>There's nothing for you to do here but I thought I'd offer a little 
  +        information about how, why and where jUDDI makes use of UUID generation.
  +      </p>
  +      <p>The UDDI specification indicates that each Business, Service, Binding 
  +        and TModel (Technical Model) is to be uniquely identified by a 
  +        Universally Unique ID (UUID). Additionally, jUDDI also uses the UUID 
  +        generator to create AuthTokens.
  +      </p>
  +      <p>Generation of UUID's typically requires access to hardware level 
  +        information that (unfortunately) is not accessible from Java. 
  +        Fortunately, the UUID specification offers an alternative method for 
  +        generating these ID's when this hardware information is not present. 
  +        By default the jUDDI implements this alternative method.
  +      </p>
  +    </section>
  +
  +    <section>
  +      <title>Logging</title>
  +      <p>When deploying jUDDI you may wish to make changes to the 
  +       juddi.properties and log4j.properties files. These files are located in 
  +       the juddi webapp's WEB-INF/classes directory. They're here because 
  +       they need to be in the classpath for jUDDI to locate and load them at 
  +       runtime. One Log4j property value that you'll most likely want to set 
  +       is log4j.appender.LOGFILE.File which specifies the name and location of 
  +       the jUDDI log file.
         </p>
       </section>
  +
     </body>
  -</document>
  \ No newline at end of file
  +</document>
  
  
  

Mime
View raw message