f5-icontrol 0.1.0

data/lib/wsdl/System.Session.wsdl

@@ -0,0 +1,1023 @@
+<?xml version="1.0" ?>
+<!--
+Copyright (c) 1996-2013, F5 Networks, Inc., Seattle, Washington. All rights reserved.  
+
+F5, F5 Networks, the F5 logo, BIG-IP, 3-DNS, iControl, GLOBAL-SITE, SEE-IT, EDGE-FX, FireGuard, Internet Control Architecture, IP Application Switch, iRules, PACKET VELOCITY, SYN Check, CONTROL YOUR WORLD, OneConnect, ZoneRunner, uRoam, FirePass, and TrafficShield are registered trademarks or trademarks of F5 Networks, Inc., in the U.S. and certain other countries. 
+
+All other trademarks mentioned in this document are the property of their respective owners. F5 Networks' trademarks may not be used in connection with any product or service except as permitted in writing by F5.
+
+-->
+<definitions name="System.Session"
+	targetNamespace="urn:iControl"
+	xmlns:tns="urn:iControl"
+	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
+	xmlns="http://schemas.xmlsoap.org/wsdl/">
+
+<!-- types -->
+
+<types>
+	<xsd:schema targetNamespace='urn:iControl'
+		xmlns='http://www.w3.org/2001/XMLSchema'
+		xmlns:SOAP-ENC='http://schemas.xmlsoap.org/soap/encoding/'
+		xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'>
+		<xsd:simpleType name="System.Session.ReturnedPath">
+			<xsd:restriction base="xsd:string">
+				<xsd:enumeration value="PATH_UNKNOWN">
+					<xsd:annotation>
+						<xsd:documentation>PATH_UNKNOWN</xsd:documentation>
+					</xsd:annotation>
+				</xsd:enumeration>
+				<xsd:enumeration value="PATH_FULL">
+					<xsd:annotation>
+						<xsd:documentation>PATH_FULL</xsd:documentation>
+					</xsd:annotation>
+				</xsd:enumeration>
+				<xsd:enumeration value="PATH_RELATIVE">
+					<xsd:annotation>
+						<xsd:documentation>PATH_RELATIVE</xsd:documentation>
+					</xsd:annotation>
+				</xsd:enumeration>
+				<xsd:enumeration value="PATH_BARE">
+					<xsd:annotation>
+						<xsd:documentation>PATH_BARE</xsd:documentation>
+					</xsd:annotation>
+				</xsd:enumeration>
+			</xsd:restriction>
+		</xsd:simpleType>
+		<xsd:simpleType name="Common.EnabledState">
+			<xsd:restriction base="xsd:string">
+				<xsd:enumeration value="STATE_DISABLED">
+					<xsd:annotation>
+						<xsd:documentation>STATE_DISABLED</xsd:documentation>
+					</xsd:annotation>
+				</xsd:enumeration>
+				<xsd:enumeration value="STATE_ENABLED">
+					<xsd:annotation>
+						<xsd:documentation>STATE_ENABLED</xsd:documentation>
+					</xsd:annotation>
+				</xsd:enumeration>
+			</xsd:restriction>
+		</xsd:simpleType>
+		<xsd:simpleType name="Common.ULong">
+			<xsd:restriction base="xsd:long"/>
+		</xsd:simpleType>
+	</xsd:schema>
+</types>
+
+<!-- message -->
+
+<message name="System.Session.get_session_identifierRequest">
+</message>
+<message name="System.Session.get_session_identifierResponse">
+	<part name="return" type="xsd:long"/>
+</message>
+
+<message name="System.Session.set_session_timeoutRequest">
+	<part name="timeout" type="xsd:long"/>
+</message>
+<message name="System.Session.set_session_timeoutResponse">
+</message>
+
+<message name="System.Session.get_session_timeoutRequest">
+</message>
+<message name="System.Session.get_session_timeoutResponse">
+	<part name="return" type="xsd:long"/>
+</message>
+
+<message name="System.Session.set_maximum_sessionsRequest">
+	<part name="sessions" type="xsd:long"/>
+</message>
+<message name="System.Session.set_maximum_sessionsResponse">
+</message>
+
+<message name="System.Session.get_maximum_sessionsRequest">
+</message>
+<message name="System.Session.get_maximum_sessionsResponse">
+	<part name="return" type="xsd:long"/>
+</message>
+
+<message name="System.Session.start_transactionRequest">
+</message>
+<message name="System.Session.start_transactionResponse">
+	<part name="return" type="xsd:long"/>
+</message>
+
+<message name="System.Session.submit_transactionRequest">
+</message>
+<message name="System.Session.submit_transactionResponse">
+</message>
+
+<message name="System.Session.rollback_transactionRequest">
+</message>
+<message name="System.Session.rollback_transactionResponse">
+</message>
+
+<message name="System.Session.set_transaction_timeoutRequest">
+	<part name="timeout" type="xsd:long"/>
+</message>
+<message name="System.Session.set_transaction_timeoutResponse">
+</message>
+
+<message name="System.Session.get_transaction_timeoutRequest">
+</message>
+<message name="System.Session.get_transaction_timeoutResponse">
+	<part name="return" type="xsd:long"/>
+</message>
+
+<message name="System.Session.set_active_folderRequest">
+	<part name="folder" type="xsd:string"/>
+</message>
+<message name="System.Session.set_active_folderResponse">
+</message>
+
+<message name="System.Session.get_active_folderRequest">
+</message>
+<message name="System.Session.get_active_folderResponse">
+	<part name="return" type="xsd:string"/>
+</message>
+
+<message name="System.Session.set_returned_pathRequest">
+	<part name="path" type="tns:System.Session.ReturnedPath"/>
+</message>
+<message name="System.Session.set_returned_pathResponse">
+</message>
+
+<message name="System.Session.get_returned_pathRequest">
+</message>
+<message name="System.Session.get_returned_pathResponse">
+	<part name="return" type="tns:System.Session.ReturnedPath"/>
+</message>
+
+<message name="System.Session.set_recursive_query_stateRequest">
+	<part name="state" type="tns:Common.EnabledState"/>
+</message>
+<message name="System.Session.set_recursive_query_stateResponse">
+</message>
+
+<message name="System.Session.get_recursive_query_stateRequest">
+</message>
+<message name="System.Session.get_recursive_query_stateResponse">
+	<part name="return" type="tns:Common.EnabledState"/>
+</message>
+
+<message name="System.Session.get_versionRequest">
+</message>
+<message name="System.Session.get_versionResponse">
+	<part name="return" type="xsd:string"/>
+</message>
+
+<!-- portType -->
+
+<portType name="System.SessionPortType">
+	<operation name="get_session_identifier">
+  	<documentation>
+ Gets a new session identifier.
+
+ This identifier is a value which uniquely identifies a user
+ session.  Once retrieved by a client, it may be included in any
+ subsequent requests to notify the iControl portal that a specific
+ request should be executed in the context of the session associated
+ with that identifier. 
+
+ Use of this identifier is completely optional. If  it is not
+ included in an iControl request, the session key defaults to the
+ user name.  Note that this is even true if you have retrieved a
+ unique session identifier.  It is also possible to have more than
+ one such unique session identifier active at the same time.
+ However, it is important to understand that each session key,
+ whether the unique identifier or the default user name represent
+ distinct sessions.  Changing a session variable in one session does
+ not effect the variable in any other session.  On the other hand,
+ if different clients have the same session key and one changes a
+ session variable, the others will see it.  The important
+ distinction is not the client being run and not the user running
+ it, but the session key for each request. 
+
+ When used, this session identifier must be passed to the iControl
+ portal via either an HTTP header or a SOAP header element.  There
+ is no preference for which transport is used, as the portal will
+ pick up either.  The client is free to use whichever is easier to
+ work with in the client's SOAP package.  If for some reason,
+ conflicting values are set in the HTTP header and SOAP header
+ element, the SOAP header element value will take precedence. 
+
+ The HTTP header holding the session identifier is named
+ "X-IControl-Session".  If used, its value must be set to the text
+ representation of the session identifier.  Thus in the HTTP
+ request, the header would look like, e.g., X-iControl-Session: 14.
+ Most SOAP packages include a straightforward way to add an HTTP
+ header to the HTTP request, so reference your documentation. 
+
+ The SOAP header element is named "session".  If used, its value
+ must be a SOAP integer element holding the session identifier. If
+ this client is intended to work with older versions of iControl, be
+ aware that the mustUnderstand SOAP header element attribute must be
+ set to 0.  Reference your SOAP package documentation for details
+ for adding a SOAP header to a request.
+
+        	</documentation>
+		<input message="tns:System.Session.get_session_identifierRequest"/>
+		<output message="tns:System.Session.get_session_identifierResponse"/>
+	</operation>
+	<operation name="set_session_timeout">
+	<documentation>
+ Sets the session timeout.
+
+ The session timeout is the amount of time for which a user session
+ has not processed a request before it is marked as eligible for
+ deletion.  For a user session without a session identifier,
+ re-using an expired session will trigger the creation of a new user
+ session with the default session values.  For a user session with a
+ session identifier, re-using an expired session will result in an
+ error.
+
+ The session timeout is a global value, so it applies equally to all
+ user sessions.  A zero timeout means that only one request can be
+ handled per user session, effectively turning off sessions.  Only
+ administrators can set this value.
+
+        	</documentation>
+		<input message="tns:System.Session.set_session_timeoutRequest"/>
+		<output message="tns:System.Session.set_session_timeoutResponse"/>
+	</operation>
+	<operation name="get_session_timeout">
+	<documentation>
+ Gets the session timeout.
+
+        	</documentation>
+		<input message="tns:System.Session.get_session_timeoutRequest"/>
+		<output message="tns:System.Session.get_session_timeoutResponse"/>
+	</operation>
+	<operation name="set_maximum_sessions">
+	<documentation>
+ Sets the maximum number of concurrent user sessions.
+
+ A system could be attacked by creating an inordinate number of
+ iControl user sessions, eventually bringing the iControl portal (or
+ the system itself) to a crawl.  If iControl is already supporting
+ this number of user sessions, subsequent attempts to create a new
+ user sessions are rejected with an error.
+
+ If this limit is set to zero, the number of user sessions is
+ unlimited.  Only administrators can set this value.
+
+        	</documentation>
+		<input message="tns:System.Session.set_maximum_sessionsRequest"/>
+		<output message="tns:System.Session.set_maximum_sessionsResponse"/>
+	</operation>
+	<operation name="get_maximum_sessions">
+	<documentation>
+ Gets the maximum number of user sessions.
+
+        	</documentation>
+		<input message="tns:System.Session.get_maximum_sessionsRequest"/>
+		<output message="tns:System.Session.get_maximum_sessionsResponse"/>
+	</operation>
+	<operation name="start_transaction">
+	<documentation>
+ Start an iControl transaction, which combines the effects of a
+ number of iControl methods into a single atomic transaction.
+
+ Once an iControl client calls start_transaction, the handling of
+ subsequent iControl requests changes until the client submits or
+ rolls back the transaction, i.e. while the transaction is open.  It
+ is important to understand the characteristics of iControl requests
+ made in this mode.  iControl requests which modify the
+ configuration are submitted for subsequent execution.  The requests
+ do not affect the configuration at the time they are made.
+ iControl requests which query the configuration are executed
+ immediately and do not see the effects of a pending transaction.
+ iControl modify requests made outside a session with an open
+ transaction affect the configuration immediately and do not see
+ effects of any pending transactions.
+
+ A transaction remains open until submit_transaction or
+ rollback_transaction is called or until it is idle for too long.
+
+ Reporting errors also differ while a transaction is open.  Some
+ classes of errors (such as invalid arguments) are returned by the
+ method itself.  The context for these errors should thus be as
+ clear as without a transaction.  However, most errors will be
+ returned by the submit_transaction call.  Note that this can make
+ it difficult to determine which iControl method caused the error.
+ If an error occurs at any time during a transaction, the
+ transaction remains open, but is marked as errant.  When
+ submit_transaction is subsequently called, the transaction will
+ actually be deleted, as if rollback_transaction has been called.
+ Note that even if an error occurs, submit_transaction or
+ rollback_transaction still must be called to properly close it.
+
+ Not all interfaces and methods support transactions.  These methods
+ are processed per normal, i.e., executed immediately and not as
+ part of the transaction. The documentation includes a note for
+ those interfaces and methods which do not. 
+
+ The contents of pending transaction cannot be queried or modified.
+ Only one transaction can be open at the same time in a single
+ user session. 
+
+        	</documentation>
+		<input message="tns:System.Session.start_transactionRequest"/>
+		<output message="tns:System.Session.start_transactionResponse"/>
+	</operation>
+	<operation name="submit_transaction">
+	<documentation>
+ Submit the transaction for execution.
+
+ When called, all of the requests submitted since start_transaction
+ was called are committed to the configuration as a single atomic
+ transaction.  If all of the requests succeed, the configuration is
+ updated.  If any of the requests fail, the transaction as a whole
+ fails and the configuration remains unchanged. 
+
+ If an error is signaled, it may be from any of the submitted
+ requests.  Nothing outside the returned error message can indicate
+ which request triggered the error.  If no requests have been queued
+ in the transaction, nothing is done and no error is signaled.   If
+ no transaction is open, an error is signaled. 
+
+        	</documentation>
+		<input message="tns:System.Session.submit_transactionRequest"/>
+		<output message="tns:System.Session.submit_transactionResponse"/>
+	</operation>
+	<operation name="rollback_transaction">
+	<documentation>
+ Roll back the transaction.
+
+ When called, all of the requests submitted since start_transaction
+ was called are un-done.  The configuration will remain unchanged. 
+
+ If no transaction is open, an error is signaled.  If no requests
+ have been queued in the transaction, nothing is done and no error
+ is signaled. 
+
+        	</documentation>
+		<input message="tns:System.Session.rollback_transactionRequest"/>
+		<output message="tns:System.Session.rollback_transactionResponse"/>
+	</operation>
+	<operation name="set_transaction_timeout">
+	<documentation>
+ Sets the transaction timeout, the amount of time that an open
+ transaction can be inactive before it is marked for deletion.
+
+ This is effectively a lower limit, an inactive open transaction may
+ be open longer than that, though is effectively unusable after that
+ point.  Expiring transactions are logged.  The transaction timeout
+ is unique for each session.
+
+        	</documentation>
+		<input message="tns:System.Session.set_transaction_timeoutRequest"/>
+		<output message="tns:System.Session.set_transaction_timeoutResponse"/>
+	</operation>
+	<operation name="get_transaction_timeout">
+	<documentation>
+ Gets the transaction timeout.
+
+        	</documentation>
+		<input message="tns:System.Session.get_transaction_timeoutRequest"/>
+		<output message="tns:System.Session.get_transaction_timeoutResponse"/>
+	</operation>
+	<operation name="set_active_folder">
+	<documentation>
+ Sets the active folder.
+
+ Most configuration objects reside in folders (see the
+ Management::Folder interface), but continually specifying the full
+ path to name an object can be wearing.  For ease, an "active
+ folder" can be specified.  When creating or accessing objects and a
+ full object path is not specified (i.e., the object path does not
+ begin with a slash (/)), the active folder is prepended to the
+ object name.  Thus if the name for an object to be created is
+ specified as "repository-a" and the active folder is
+ /george/server, the full path for the created object is
+ /george/server/repository-a.  Note that relative paths are also
+ allowed in the object identifier, so that if the active folder is
+ /george/server and the given object identifier is
+ virtual/repository-a, then the full object path is
+ /george/server/virtual/repository-a.
+
+ The active folder may be the root folder (/), but that is only
+ usable when querying.
+
+ If for some reason, neither the currently active folder nor the
+ newly requested active folder exist, the currently active folder
+ will be set to the user's default folder.
+
+        	</documentation>
+		<input message="tns:System.Session.set_active_folderRequest"/>
+		<output message="tns:System.Session.set_active_folderResponse"/>
+	</operation>
+	<operation name="get_active_folder">
+	<documentation>
+ Gets the active folder.
+
+        	</documentation>
+		<input message="tns:System.Session.get_active_folderRequest"/>
+		<output message="tns:System.Session.get_active_folderResponse"/>
+	</operation>
+	<operation name="set_returned_path">
+	<documentation>
+ Sets the type of path information returned with object names.
+
+        	</documentation>
+		<input message="tns:System.Session.set_returned_pathRequest"/>
+		<output message="tns:System.Session.set_returned_pathResponse"/>
+	</operation>
+	<operation name="get_returned_path">
+	<documentation>
+ Gets the type of path information returned with object names.
+
+        	</documentation>
+		<input message="tns:System.Session.get_returned_pathRequest"/>
+		<output message="tns:System.Session.get_returned_pathResponse"/>
+	</operation>
+	<operation name="set_recursive_query_state">
+	<documentation>
+ Sets the state to recursively query the contents of the
+ active folder. As of 11.4.0, this setting applies also to
+ delete_all_x operations.
+
+ If not set, any query will return objects in the active folder
+ only.  If set, any query will return objects in the active folder,
+ plus objects in any sub-folders under that active folder no matter
+ how deeply nested.
+
+ Note, regarding other recursive operations: when folders
+ were introduced, the behavior of delete_all_x methods, such
+ as LocalLB::Pool::delete_all_pools, was unspecified with
+ respect to folders. (It was unspecified in which folders to
+ apply the operation).  As of 11.4.0, the behavior of
+ delete_all_x methods is clarified: delete_all_pools and
+ similar methods operate on objects in the active folder,
+ and only there. If you would like to delete all pools in
+ the active folder and folders below it, enable recursive
+ query using this method.  If you would like to delete all
+ pools in a top-level folder (partition) and below, set the
+ active folder to the desired folder and turn on recursive
+ query.
+
+        	</documentation>
+		<input message="tns:System.Session.set_recursive_query_stateRequest"/>
+		<output message="tns:System.Session.set_recursive_query_stateResponse"/>
+	</operation>
+	<operation name="get_recursive_query_state">
+	<documentation>
+ Gets the state to recursively query the contents of the active
+ folder.
+
+        	</documentation>
+		<input message="tns:System.Session.get_recursive_query_stateRequest"/>
+		<output message="tns:System.Session.get_recursive_query_stateResponse"/>
+	</operation>
+	<operation name="get_version">
+	<documentation>
+ Gets the version information for this interface.
+
+        	</documentation>
+		<input message="tns:System.Session.get_versionRequest"/>
+		<output message="tns:System.Session.get_versionResponse"/>
+	</operation>
+</portType>
+
+<!-- binding -->
+
+<binding name="System.SessionBinding" type="tns:System.SessionPortType">
+	<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
+	<operation name="get_session_identifier">
+	<documentation>
+ Gets a new session identifier.
+
+ This identifier is a value which uniquely identifies a user
+ session.  Once retrieved by a client, it may be included in any
+ subsequent requests to notify the iControl portal that a specific
+ request should be executed in the context of the session associated
+ with that identifier. 
+
+ Use of this identifier is completely optional. If  it is not
+ included in an iControl request, the session key defaults to the
+ user name.  Note that this is even true if you have retrieved a
+ unique session identifier.  It is also possible to have more than
+ one such unique session identifier active at the same time.
+ However, it is important to understand that each session key,
+ whether the unique identifier or the default user name represent
+ distinct sessions.  Changing a session variable in one session does
+ not effect the variable in any other session.  On the other hand,
+ if different clients have the same session key and one changes a
+ session variable, the others will see it.  The important
+ distinction is not the client being run and not the user running
+ it, but the session key for each request. 
+
+ When used, this session identifier must be passed to the iControl
+ portal via either an HTTP header or a SOAP header element.  There
+ is no preference for which transport is used, as the portal will
+ pick up either.  The client is free to use whichever is easier to
+ work with in the client's SOAP package.  If for some reason,
+ conflicting values are set in the HTTP header and SOAP header
+ element, the SOAP header element value will take precedence. 
+
+ The HTTP header holding the session identifier is named
+ "X-IControl-Session".  If used, its value must be set to the text
+ representation of the session identifier.  Thus in the HTTP
+ request, the header would look like, e.g., X-iControl-Session: 14.
+ Most SOAP packages include a straightforward way to add an HTTP
+ header to the HTTP request, so reference your documentation. 
+
+ The SOAP header element is named "session".  If used, its value
+ must be a SOAP integer element holding the session identifier. If
+ this client is intended to work with older versions of iControl, be
+ aware that the mustUnderstand SOAP header element attribute must be
+ set to 0.  Reference your SOAP package documentation for details
+ for adding a SOAP header to a request.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="set_session_timeout">
+	<documentation>
+ Sets the session timeout.
+
+ The session timeout is the amount of time for which a user session
+ has not processed a request before it is marked as eligible for
+ deletion.  For a user session without a session identifier,
+ re-using an expired session will trigger the creation of a new user
+ session with the default session values.  For a user session with a
+ session identifier, re-using an expired session will result in an
+ error.
+
+ The session timeout is a global value, so it applies equally to all
+ user sessions.  A zero timeout means that only one request can be
+ handled per user session, effectively turning off sessions.  Only
+ administrators can set this value.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="get_session_timeout">
+	<documentation>
+ Gets the session timeout.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="set_maximum_sessions">
+	<documentation>
+ Sets the maximum number of concurrent user sessions.
+
+ A system could be attacked by creating an inordinate number of
+ iControl user sessions, eventually bringing the iControl portal (or
+ the system itself) to a crawl.  If iControl is already supporting
+ this number of user sessions, subsequent attempts to create a new
+ user sessions are rejected with an error.
+
+ If this limit is set to zero, the number of user sessions is
+ unlimited.  Only administrators can set this value.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="get_maximum_sessions">
+	<documentation>
+ Gets the maximum number of user sessions.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="start_transaction">
+	<documentation>
+ Start an iControl transaction, which combines the effects of a
+ number of iControl methods into a single atomic transaction.
+
+ Once an iControl client calls start_transaction, the handling of
+ subsequent iControl requests changes until the client submits or
+ rolls back the transaction, i.e. while the transaction is open.  It
+ is important to understand the characteristics of iControl requests
+ made in this mode.  iControl requests which modify the
+ configuration are submitted for subsequent execution.  The requests
+ do not affect the configuration at the time they are made.
+ iControl requests which query the configuration are executed
+ immediately and do not see the effects of a pending transaction.
+ iControl modify requests made outside a session with an open
+ transaction affect the configuration immediately and do not see
+ effects of any pending transactions.
+
+ A transaction remains open until submit_transaction or
+ rollback_transaction is called or until it is idle for too long.
+
+ Reporting errors also differ while a transaction is open.  Some
+ classes of errors (such as invalid arguments) are returned by the
+ method itself.  The context for these errors should thus be as
+ clear as without a transaction.  However, most errors will be
+ returned by the submit_transaction call.  Note that this can make
+ it difficult to determine which iControl method caused the error.
+ If an error occurs at any time during a transaction, the
+ transaction remains open, but is marked as errant.  When
+ submit_transaction is subsequently called, the transaction will
+ actually be deleted, as if rollback_transaction has been called.
+ Note that even if an error occurs, submit_transaction or
+ rollback_transaction still must be called to properly close it.
+
+ Not all interfaces and methods support transactions.  These methods
+ are processed per normal, i.e., executed immediately and not as
+ part of the transaction. The documentation includes a note for
+ those interfaces and methods which do not. 
+
+ The contents of pending transaction cannot be queried or modified.
+ Only one transaction can be open at the same time in a single
+ user session. 
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="submit_transaction">
+	<documentation>
+ Submit the transaction for execution.
+
+ When called, all of the requests submitted since start_transaction
+ was called are committed to the configuration as a single atomic
+ transaction.  If all of the requests succeed, the configuration is
+ updated.  If any of the requests fail, the transaction as a whole
+ fails and the configuration remains unchanged. 
+
+ If an error is signaled, it may be from any of the submitted
+ requests.  Nothing outside the returned error message can indicate
+ which request triggered the error.  If no requests have been queued
+ in the transaction, nothing is done and no error is signaled.   If
+ no transaction is open, an error is signaled. 
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="rollback_transaction">
+	<documentation>
+ Roll back the transaction.
+
+ When called, all of the requests submitted since start_transaction
+ was called are un-done.  The configuration will remain unchanged. 
+
+ If no transaction is open, an error is signaled.  If no requests
+ have been queued in the transaction, nothing is done and no error
+ is signaled. 
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="set_transaction_timeout">
+	<documentation>
+ Sets the transaction timeout, the amount of time that an open
+ transaction can be inactive before it is marked for deletion.
+
+ This is effectively a lower limit, an inactive open transaction may
+ be open longer than that, though is effectively unusable after that
+ point.  Expiring transactions are logged.  The transaction timeout
+ is unique for each session.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="get_transaction_timeout">
+	<documentation>
+ Gets the transaction timeout.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="set_active_folder">
+	<documentation>
+ Sets the active folder.
+
+ Most configuration objects reside in folders (see the
+ Management::Folder interface), but continually specifying the full
+ path to name an object can be wearing.  For ease, an "active
+ folder" can be specified.  When creating or accessing objects and a
+ full object path is not specified (i.e., the object path does not
+ begin with a slash (/)), the active folder is prepended to the
+ object name.  Thus if the name for an object to be created is
+ specified as "repository-a" and the active folder is
+ /george/server, the full path for the created object is
+ /george/server/repository-a.  Note that relative paths are also
+ allowed in the object identifier, so that if the active folder is
+ /george/server and the given object identifier is
+ virtual/repository-a, then the full object path is
+ /george/server/virtual/repository-a.
+
+ The active folder may be the root folder (/), but that is only
+ usable when querying.
+
+ If for some reason, neither the currently active folder nor the
+ newly requested active folder exist, the currently active folder
+ will be set to the user's default folder.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="get_active_folder">
+	<documentation>
+ Gets the active folder.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="set_returned_path">
+	<documentation>
+ Sets the type of path information returned with object names.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="get_returned_path">
+	<documentation>
+ Gets the type of path information returned with object names.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="set_recursive_query_state">
+	<documentation>
+ Sets the state to recursively query the contents of the
+ active folder. As of 11.4.0, this setting applies also to
+ delete_all_x operations.
+
+ If not set, any query will return objects in the active folder
+ only.  If set, any query will return objects in the active folder,
+ plus objects in any sub-folders under that active folder no matter
+ how deeply nested.
+
+ Note, regarding other recursive operations: when folders
+ were introduced, the behavior of delete_all_x methods, such
+ as LocalLB::Pool::delete_all_pools, was unspecified with
+ respect to folders. (It was unspecified in which folders to
+ apply the operation).  As of 11.4.0, the behavior of
+ delete_all_x methods is clarified: delete_all_pools and
+ similar methods operate on objects in the active folder,
+ and only there. If you would like to delete all pools in
+ the active folder and folders below it, enable recursive
+ query using this method.  If you would like to delete all
+ pools in a top-level folder (partition) and below, set the
+ active folder to the desired folder and turn on recursive
+ query.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="get_recursive_query_state">
+	<documentation>
+ Gets the state to recursively query the contents of the active
+ folder.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+
+	<operation name="get_version">
+	<documentation>
+ Gets the version information for this interface.
+
+        	</documentation>
+		<soap:operation soapAction="urn:iControl:System/Session"/>
+		<input>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</input>
+		<output>
+			<soap:body
+				use="encoded"
+				namespace="urn:iControl:System/Session"
+				encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
+		</output>
+	</operation>
+</binding>
+
+<!-- service -->
+
+<service name="System.Session">
+	<documentation>
+ The Session interface allows you to manage iControl sessions.
+
+ An iControl session is a set of attributes which can persist across
+ iControl requests for a specific user.  These values currently include
+ the active folder and the transaction.
+
+ By default, a user session is identified by the user's name.  However,
+ finer grained control over user session can be gained via an explicit
+ session identifier, which can be requested by a user and included in
+ any subsequent requests which are intended to be included in that
+ session.
+
+ This interface does not support transactions.
+
+        	</documentation>
+	<port name="System.SessionPort" binding="tns:System.SessionBinding">
+		<soap:address location="https://url_to_service"/>
+	</port>
+</service>
+</definitions>