The RETS Reference Implementation is written in Java, the server is a Java servlet and the client consists of API classes and JSP pages. This software was developed for Apache Tomcat 4.0 as the Servlet/JSP engine, and MySQL is the database engine. The RETS Reference Implementation should work with any Servlet engine that supports the 2.2 or 2.3 Servlet Specification and the 1.1 or 1.2 JSP specification.

Here is an excerpt from the Developers Guide dealing with the RETS Login process from the RETS Client side. It illustrates the degree of thought and detail available to developers….


In the following sequence diagram, "loginAction.jsp" is parsed when a user selects submit on the login page. "loginAction.jsp" creates an instance of RETSLoginTransaction and an instance of RETSConnection. The "execute()" method of the RETSConnection object is called passing the LoginTransaction as an argument. RETSConnection sends the request to the RETSServer identified by the "serverURL" variable of the Transaction. The RETSServer response is parsed by the RETSConnection object and the "set Response()" method is called on the Transaction object to complete the transaction. "loginAction.jsp" calls the Transaction's "getResponseMap()" method and formats the response for display to the browser.













It is possible to see even more about what is happening by using the "Monitor" choices on the left.

Apache Log4J is used for logging by all classes in the reference implementation.
A servlet is running that streams the contents of an Apache Log4J file to an http client.

By default, server side classes write to the file "/tmp/retsServer.log" and client side classes write to the file "/tmp/retsClientAPI.log".

Hence, the Monitor provides you a view of the logfiles for either the RETS Client Side or the RETS Server.












The "Search Office DMQL Query" field defaults to a valid DMQL query. A Search Office Transaction is sent to the RETS Server when the Submit button is selected.












The input here is not DMQL, the RETS Client builds the DMQL before the Transaction request is sent to the RETS Server












The reference implementation is delivered with three MySQL tables; AGENTS, OFFICES and PROPERTIES. These are populated with a sample of actual data. Of course you can see what fields are supported for the queries by looking at the underlying RETS Metadata for Property. This can be done via the "View Metadata" choice on the left.


Bruce Toback's DMQLtoSQL classes are used to implement the DMQL support in the reference implementation. For more information on Bruce Toback's DMQLtoSQL, see the following URL:

http://www.optc.com/~btoback/DMQLtoSQLTest/doc/index.html












The supplied RETS Client also exercises a GetObject transaction every time a Property Search is performed, the image at the bottom of the page is the result of the GetObject transaction.












The ID field identifies the resource followed by the class, separated by a colon ':' (see Real Estate Data Interchange Standard: Real Estate Transaction Specification Version 1.0 Section 11.) A GetMetadata Transaction is sent to the RETS Server when the Submit button is selected.