HTCondorWiki: Soap Wisdom

 {section: Overview}
 
-All of the condor daemons can talk soap as detailed in {link: http://research.cs.wisc.edu/condor/manual/v7.6/4_5Application_Program.html#SECTION00551000000000000000 the 7.6 manual}
+All of the HTCondor daemons can talk soap as detailed in {link: http://research.cs.wisc.edu/condor/manual/v7.6/4_5Application_Program.html#SECTION00551000000000000000 the 7.6 manual}
 
 For a very clear and concise intro to SOAP messaging, see http://www.soapware.org/bdg
 
-A good resource is a 2006 Condor Week Powerpoint presentation that gives an overview using Condor's SOAP interface and some code snippets in Java:
+A good resource is a 2006 HTCondor Week Powerpoint presentation that gives an overview using HTCondor's SOAP interface and some code snippets in Java:
 {link: http://www.cs.wisc.edu/condor/CondorWeek2006/presentations/farrellee_tannenba_APIs.ppt}
 
 Barebones netcat example: (assumes somehost.example.com:9618 is your soap-enabled collector)
@@ -48,9 +48,9 @@
 </SOAP-ENV:Body></SOAP-ENV:Envelope>
 {endcode}
 
-Valid function calls such as getVersionString in the above example can be found in the different wsdl files provided with condor. Condor ships with wsdl files for all daemons and they are located in lib/webservice in the binary releases. Also note the use of the namespace urn:condor, you may have to specify this in your client library.
+Valid function calls such as getVersionString in the above example can be found in the different wsdl files provided with HTCondor. HTCondor ships with wsdl files for all daemons and they are located in lib/webservice in the binary releases. Also note the use of the namespace urn:condor, you may have to specify this in your client library.
 
-Each daemon provides a separate SOAP server. The only condor daemon that runs on a static port by default is the collector (port 9618). Therefore, in order to connect to other daemons in your pool (whose ports are randomized), you have two options:
+Each daemon provides a separate SOAP server. The only HTCondor daemon that runs on a static port by default is the collector (port 9618). Therefore, in order to connect to other daemons in your pool (whose ports are randomized), you have two options:
 
 1: Configure any daemons you care about to have static port configurations. In the case of the schedd, this would be done using something like SCHEDD_ARGS = -p 8080. This can simplify client code. You can further simplify client code by updating the location parameter found at the bottom of any wsdl files you make use of.
 
@@ -60,13 +60,13 @@
 
 This is a minimalist example to get you going. It is tested with {link: https://fedorahosted.org/suds/ suds-0.3.5} and python 2.4 (should be python 2.3 compatible). It should be helpful to get going with other languages, as well.
 
-{subsection: Condor Configuration}
+{subsection: HTCondor Configuration}
 
 Note that **this is a really insecure configuration**, especially for public hosts. See {link: http://www.cs.wisc.edu/condor/manual/v7.3/4_5Application_Program.html#SECTION00551400000000000000 the manual} for more info.
 
-Also note that we are exposing the wsdl files on each server using WEB_ROOT_DIR. This is especially important in mixed condor version environments since it ties the wsdl to the server it is used on.
+Also note that we are exposing the wsdl files on each server using WEB_ROOT_DIR. This is especially important in mixed HTCondor version environments since it ties the wsdl to the server it is used on.
 
-Add the below to all condor configurations
+Add the below to all HTCondor configurations
 
 {code}
 ENABLE_SOAP = TRUE
@@ -161,7 +161,7 @@
 
 Notes:
 
-1: The condor classad structures are a little strange. Instead being a mapping of string keys to native soap types, they are an array of mappings that look like this:
+1: The HTCondor classad structures are a little strange. Instead being a mapping of string keys to native soap types, they are an array of mappings that look like this:
 {code}(item){
    name = "CondorVersion"
    type = "STRING-ATTR"
@@ -187,9 +187,9 @@
 
 {section: Additional Examples}
 
-{link: http://spinningmatt.wordpress.com/2009/11/02/submitting-a-workflow-to-condor-via-soap-using-java/ This blog post} explains how to submit a DAGman job to Condor using the SOAP interface from Java.
+{link: http://spinningmatt.wordpress.com/2009/11/02/submitting-a-workflow-to-condor-via-soap-using-java/ This blog post} explains how to submit a DAGman job to HTCondor using the SOAP interface from Java.
 
-Here are a few additional examples of using the Condor SOAP interface, this time in Perl.  These examples assume that the _condor_schedd_ has been configured to run on well-known port 8080 as described above. Note that you should be using a very recent version of the SOAP::Lite module. 0.60 won't work, 0.712 will.
+Here are a few additional examples of using the HTCondor SOAP interface, this time in Perl.  These examples assume that the _condor_schedd_ has been configured to run on well-known port 8080 as described above. Note that you should be using a very recent version of the SOAP::Lite module. 0.60 won't work, 0.712 will.
 
 {subsection: Get Version String in Perl}
 {code}