Installation Guide

This page provides a walkthrough of the steps needed to install the FUSION Semantic Registry. The installation file is a standard Web Application Archive (WAR) file that can be deployed on any Servlet 2.4 compliant Web Application container.


Installation pre-requisites

  1. A Web Application container (e.g. Apache Tomcat 5.5.x).

  2. A UDDI v2 compliant server (e.g. jUDDI v0.9rc4).

  3. If the Web Application container and the UDDI server are installed on different machines, make sure that the first is able to access the second over the network (e.g. proxy information may need to be provided as part of Tomcat's startup parameters if the Tomcat host machine is behind a proxy).

  4. It is assumed that you have obtained a username and a password which allow you to have read/write access to the UDDI server, and that you know the UDDI server's "inquiryURL" and "publishURL".


Installation process

  1. Deploy the SemanticRegistry1.0.war file to the Web Application container (e.g. TOMCAT_HOME\webapps\).

  2. Create a Web service client or use a WSDL/SOAP client tool (e.g. Eclipse WTP Web Service Explorer or SOAP UI) to invoke the setupStandardConfiguration operation that is provided by the Semantic Registry AdminManager service.

  3. Provide inquiryURL, publishURL, username and password for your UDDI server as input data parameters for the setupStandardConfiguration operation. The Semantic Registry will use this information to connect to the UDDI server, publish five canonical tModels which are necessary for the Semantic Registry to function, and will return the tModel names and keys.

  4. Copy the content of the response message that is returned by the setupStandardConfiguration operation.

  5. Locate the registry.properties file that has been unpacked inside the \webapps\SemanticRegistry1.0\WEB-INF\classes directory of the Web Application container and open it with a text editor.

  6. Paste the content of the response message that was returned by the setupStandardConfiguration operation in the file, such that tModel "name=key" assignments exist for all five canonical tModels.
    Example:
    • SAWSDL_Document_URL_tModel=uuid:D5C30D20-DBAC-11DC-8D20-F06637080EBE
    • Category_Annotation_tModel=uuid:D5C57E20-DBAC-11DC-BE20-B2E1BAA1BAF0
    • Input_Annotation_tModel=uuid:D5C57E20-DBAC-11DC-BE20-EAD066A5C022
    • Output_Annotation_tModel=uuid:D5C7C810-DBAC-11DC-8810-AA443D92C136
    • Subsumption_Indexing_tModel=uuid:D5C7C810-DBAC-11DC-8810-B7FB36BEAEE8

  7. Set the appropriate URL values for the publish_url and inquiry_url variables.
    Example:
    • publish_url=http://localhost:9080/juddi/publish
    • inquiry_url= http://localhost:9080/juddi/inquiry

  8. Set the appropriate URI value for the eai_ontology_physical_URI variable. The URI must point to the OWL file that will serve as the domain ontology for the specific EAI scenario. The Semantic Registry installation does not need to have write access to the specified file; read-only access is sufficient.
    Example:
    • eai_ontology_physical_URI=http://www.seerc.org/fusion/semanticregistry/tutorial/domainontology.owl

  9. Set the appropriate URI value for the srkb_ontology_physical_URI variable. The URI must point to the OWL file that will serve as the store for the Semantic Registry Knowledge Base (write access is required). The SRKB ontology must contain exactly one owl:imports statement pointing to the domain ontology mentioned in the previous step. Refer to the next figure for an analysis of the import structure that the domain ontology and SRKB ontology must respect.
    Example:
    • srkb_ontology_physical_URI=file:///C:/SemanticRegistryKB.owl

  10. Save changes back to the registry.properties file and restart the Web Application container. If the configuration parameters are correct, the Semantic Registry should be fully functional.


Ontology import structure pre-requisites

The following figure illustrates the import structure to which the domain ontology and the SRKB ontology must adhere to. In summary, the rules to be observed are the following:

One option is to use the FUSION Ontology as the domain ontology for the FUSION Semantic Registry. Another option is to create your own domain ontology, like the example ontology provided here, which imports three small ontologies that are used for defining service categories, service inputs and outputs, and service requests (RFPs). An example of a semantically-annotated WSDL file which has been annotated with classes defined in those example ontologies can be found here.

imports