Real Estate Data Exchange standard documentation
Ver. 0.93
29.10.2007
Table of Contents
2.1. Location of the XML Schema, Example WSDL and Documentation
2.2. Copyright notice & Terms of Use
2.3. Change requests and it’s workflow
2.4. Version changes and notification list
3. Real Estate Data Exchange Description
3.3. Security and Authentication
4.2 Simple PHP Client: client.php & RealEstateDataExchange.php
4.3 Sample Web Service Server with SoapServer class: webservice.php.
4.4 Sample Web Service Handler: ServiceHandler.php
The following people and organizations have been involved in developing this document.
The purpose of this standard is to define a fast, reliable and powerful way to transfer real estate offers and projects between different environments. The goals of the project are:
· To provide schema which is unique and usable in different countries, real estate portals, real estate companies;
· To allow real estate offers and projects data exchange between different countries;
· To provide data exchange methods for simplifying development processes and making data exchange flexible;
This standard provides new and more widely used methods for data transfer by using WSDL to specify mandatory methods for all parties and SOAP as data transfer method and of course a better XML Schema that should fit to interested parties. The standard allows parties do develop only a simpler SOAP client to fetch information, but the standard recommends having Server on both sides to allow real estate companies to force updates of information without having to wait for the next scheduled update. This should provide a better and faster data update rate in portals and homepages. Authors highly suggest everyone using this standard to implement both the Soap Client and Soap Server as it provides vastly more possibilities to synchronize and verify the data.
The use of this standard, or any part of it, including the sample codes are free for everyone, but it is required for the people who wish to use it to notify us about it, as this will allow us to notify you when we change some part of this standard, and also gives us a better understanding of how and where this standard is being used.
As the proper change request workflow is not set yet, all change requests should go to reigo@girf.ee until further notice.
Currently there is no official mailing list or notification list for the changes of this standard, but we are planning to have both once the standard is being approved and taken over by EKFL.
Note: We strongly recommend you to quickly read through the XML Schema file also, as most complicated schema elements are documented inside it.
Example how the push method of an object update should occur:
Brokers from the Information system part initiate the contact by telling the Portal to update that particular object information. Portal then fetches that object, and updates its information.
Older
and also reliable method that most systems currently use:
Portal
initiates the contact regularly(3 times a day, every 1h etc) by asking objects
by getObjectIdsByStatus or getObjectIdsByModifiedDateSince and after that it
iterates through the list and gets the objects by getObjectById.
We strongly recommend all Real Estate Portals and Information System developers to implement all the web services provided in the included WSDL file of this Standard. This means, that all systems that use this standard, should be able to accept requests from other parties to update information, and should be able to also send the update completed notification to the other party about successful import and provide them with the correct externalUrl and other metadata from their system.
Here is a graphical presentation of the REDE.wsdl file:
For authentication there are more than one way, but we recommend the simple and most used version – all requests include the username and password.
In all cases, the security model should be selected by both partners to suit their needs, and partners must provide each other with the correct usernames and passwords where appropriate.
This standard does not set any rules on how and by whom the usernames and passwords are generated, or how the security models are used. In other words, there is no central database of users, and there are no real limitations on how to authenticate your partners.
Location group is a bit special in handling. As it seemed impossible for the development group to specify all possible locations on supporting countries, we opted for a pretty free method.
Location component is divided into 3 parts:
Specific fault texts or codes are yet to be specified, but at the moment all faults should be treated as per-object or per-broker failures, and they shouldn’t stop the import of other objects or brokers etc.
Samples are here just to get you started and to provide you a good understanding how the data exchange should work, it is not possible or cost-effective for us to develop examples of every possible client and server methods, but we have covered the most basic and needed functionality. Expect more examples and better examples to follow with further versions.
We will try to provide Java and C# & .NET examples also in the future.
The following examples require PHP5 with SOAP extension. You probably might have to tweak them to get them to work, specially the location of the WSDL file and of course the location of your web services inside the WSDL file(this is in the very bottom of the file).
If you are limited the older PHP4 that didn’t have the Soap support, then you should look into NuSoap or some other equivalent PHP Soap library.
4.1.3 Sample Web Service Handler:
ServiceHandler.phps4.1.4
Download all PHP Samples: PHPExamples.zip
29.10.2007
26.10.2007
19.10.2007
18.09.2007
07.09.2007
15.08.2007
15.08.2007
07.08.2007
23-07-2007
18-07-2007
05-07-2007
28-06-2007