We will begin this discussion with a little background information about RETS. This is by no means a complete discussion of RETS. It is only meant to suffice in getting the reader up to speed with the technology behind the Real Estate Transaction Standard.
RETS is an acronym for the Real Estate Transaction Standard. The Real Estate Transaction Standard is the new open standard for exchanging real estate transaction information. The National Association of Realtors (NAR) implemented this standard in March of 99. Consisting of a transaction specification and a standard Extensible Markup Language (XML) Document Type Definition (DTD), RETS is being implemented by many real estate industry leaders in their next generation of real estate information systems.
Back before RETS came along, brokerage firms attempting to gather data from different local MLSs had to somehow deal with the disparate formats each MLS maintained. This usually meant that vendors had to support/design x number of applications, one for each of the different MLSs to support. Not only did supporting various data formats prove to be somewhat awkward and cumbersome, but it led to a number of instances where the data collection system "broke" due to an alteration of the data format from the MLS.
This led the NAR to begin the development of a set of standards to help solve some of the industry's data exchange issues. So, in February 1999, a task force met to address these data standards. The group's mission was defined as follows: " Define detailed technical standards for Internet based communication and exchange of real estate property information. " [1]
The task force ended up choosing a set of HTTP-based transactions. These transactions provide clients with a standard means to retrieve data from the MLS hosts. In the words of the task force, an HTTP based system was selected for a number of reasons:
HTTP is TCP/IP based, which provides a reliable, error-free communications link that is widely and inexpensively available to users.
HTTP is a well understood, well documented Internet standard.
HTTP can pass through most firewalls without additional setup.
HTTP is well supported by many third party tools, making initial development easier and less prone to errors.
An HTTP based transaction set lends itself to easy testing and experimentation in a browser environment, which will lead to quicker understanding and hence better acceptance in the vendor community.
Basically, a RETS Client can be considered to be any piece of software that meets the minimum compliance standards for communicating with a RETS Server, based on the requirements outlined in the RETS Specification. Communication with a RETS Server occurs via HTTP and TCP/IP, using message headers. Currently, the specification supports 9 distinct transactions--3 of which are required, and the remaining 6 are optional. Each transaction is described below in further detail. Those transactions which are optional are also noted below.[1] & [2]
The Login transaction is the first transaction that a client must issue during a session with a host. It identifies to the host the username and password of the human user, giving the host the opportunity to reject the login request or apply business rules as needed. The Login transaction uses a simple challenge-response method called Digest Authentication in order to prevent sending the user's password over the Internet in clear text form, providing a minimal level of security [editor's note: Basic Authentication is also acceptable, but it is not considered as secure as Digest].
In the response, the host provides the client software with a number of valuable pieces of information, the most important of which is a list of URLs which give the client access to the various transactions and other capabilities of the host. Besides the standard (required) transactions, the host can optionally provide additional URL links for additional capabilities, which help to ensure that the standard is not only extensible in future standards, but is also extensible by private agreement.
The LoginComplete transaction is the second part of the Login transaction that enables software copy protection security/piracy prevention. It allows the client and host to synchronize the information kept to prevent piracy. Technically, it initiates the second phase of a two-phase commit algorithm.
The Action transaction is used to provide the client with bulletin information or the notification of an email message. The client application should provide a means for the user to view the retrieved document. This transaction must be performed immediately after the Login transaction.
The GetObject transaction is used to retrieve additional information that hosts store related to specific data objects. This transaction is used primarily to retrieve multimedia types associated with host records (house pictures, agent photos, sound clips, 3D tours, etc.). It also allows the client to download the latest copy of the metadata, thereby enabling the client to configure itself to the host and adapt to changes.
The Logout transaction terminates a particular client/host session. In effect, the Logout transaction tells the host that the client has completed all processing that is going to be done in this session, and allows the host to free up any information it had been keeping on behalf of the client. It also ensures that the host logs the user out of the system, and for systems that prevent simultaneous login of the same username, ensures that the username can log in again in the future.
The Search transaction is the primary workhorse transaction of RETS. It enables a client to request a set of data from the host, and gives the host a number of additional parameters with which to work. These parameters include things like the type of data to be returned, the query itself, the data fields to return and the format for the data returned. The standard query language is also defined as part of the search transaction. For instance, a client can request "All active properties in area 512 with a list price of between $200,000 and $250,000 with 3 or more bathrooms, with the return data set of no more than 50 records to be formatted in COMPACT-DECODED format". The host executes the query and returns the data or an error code to the client for further processing. The Search transaction is very detailed, and the reader is referred to the standards document for further information on this transaction.
The Get [File] transaction simply allows the client to get an arbitrary file from a specific URL on the host. It is not specified how the client can obtain the name of the file, nor is it specified what business rules might need to be enforced. Get [File] allows additional host-specific functionality to be built into specific clients. This transaction might be used to acquire additional host information or to download client software updates.
The Change Password transaction provides a means for the user to change their password. The new password is appended to the username and encrypted using the Data Encryption Standard (DES), ANSI X3.92, using a hash of the old password as the key.
The Update transaction is used to modify data on the server. The client transmits information describing the update to perform. The information is then validated by the server. If there are errors in the data, the server returns an error reply. If there are no errors, the record as it was inserted/updated on the server will be returned. The record is returned in the same manner as a record is returned from a search.
The GetMetadata transaction is used to retrieve structured information known as metadata related to the system entities. Metadata requested and returned from this transaction are requested and returned as MIME media types.
The Open RETS Client (or more fondly known as ORC), is a client application designed to retrieve Multiple Listing Service (MLS) related data from a remote/local RETS compatible server. The ORC supports the majority of functional operations as defined per the Real Estate Transaction Standard Protocol Specification, versions 1.0 and 1.5.
More specfically, the ORC is a command-line application written in Java and licensed under the GNU GPL. Designed around a Model-View-Controller (MVC) architecture, the ORC has been separated into a presentation layer (view), an application logic layer (controller), and a business logic layer (model)--Figure 1. Currently, the ORC supports the following transactions:
Login Transaction
Logout Transaction
Action Transaction
Search Transaction
GetMetadata Transaction
Get Transaction (not supported)
GetObject Transaction
Update Transaction (not supported)
Change Password Transaction (not supported)
By de-coupling the business logic (model), from the presentation (UI) view, we avoid the intermingling of low-level application related code with the higher level end-user interface. An added bonus of this sort of architecture is that if, or when a Graphical User Interface (GUI) replaces the command-line UI, the amount of redesign will be minimal, since only the presentation view is significantly altered. The motivation behind using a MVC paradigm includes:[3]
To support cohesive model definitions that focus on the domain processes, rather than on computer interfaces.
To allow separate development of the model and user interface layers.
To minimize the impact of requirements changes in the interface upon the domain layer.
To allow new views to be easily connected to an existing domain layer, without affecting the domain layer.
To allow multiple simultaneous views on the same model object.
To allow execution of the model layer, independent of the user interface layer, such as in a batch-mode system.
To allow easy porting of the model layer to another user interface framework.