RETS2 Charter
From RETS Community Wiki
Contents |
[edit] Vision
The Realtor serves as the first point of contact between the consumer and the real estate transaction community; RETS2 will help anchor that role with appropriate data and process standards for the software of today as well as creating a fertile ground for new automated service models of tomorrow.
[edit] Mission
To build on the success of RETS 1.x by:
- Greater conformance to web-related IT standards (e.g. Web Services, SOAP)
- Expanding the way RETS can support the overall real estate transaction (moving the property data to a more diverse user community, support for other real estate data beyond the listing)
- Expanding to accommodate greater explicit consideration for Security concerns (tracking more closely with WS-Security and SAML)
[edit] Value proposition
RETS2 will enable more data about more aspects of the real estate transaction to be more easily coordinated across service providers; continuing to drive out the overhead of incompatible systems and software amongst trading partners.
[edit] Target Audiences
[edit] Real Estate Transaction Software Community
Thinking past the current MLS model
- MLS vendors or MLS with custom software
- Third Party Agent Productivity Vendors
- Data Aggregators
- Brokers with custom software
- Transaction Management System Vendors
- Mortgage Origination Software
- Valuation (appraisal, avm) Software
- Closing, Recording software vendors
[edit] Real Estate Software User Community
- Buyers and Sellers
- Agents, Brokers, MLS Organizations, Associations
- Mortgage Companies, Banks, Appraisal Companies, Title Companies
- Academic Community
[edit] Architecture
- Synchronous (Request/Response) & Asynchronous (Message-driven).
- More than SOAP, more than Web Services, RETS2 should support a Service-Oriented Architecture.
- New services should be easily used by choreography and orchestration products/tools (BizTalk, Collaxa & SeeBeyond (all BPEL) or WebMethods).
- Move away from Table-centric model to a Business-Service/Data Repository Model.
- Creates RETS2 as a number of layers. Separate Transport from Content, etc. Web services tend to be designed this way. Each ‘black box’ doesn't know the contents of the other boxes.
- Establish a Roadmap/Timeline of when new concepts/technologies will be incorporated.
[edit] Performance Issues
- Retention of COMPACT format -Now simplified and renamed as DELIMITED in RETS2
- Implications and solutions for using standard SOAP toolkits
- Performance in a pure-XML environment
- Very large payloads must be processed efficiently - MTOM/STAX allow for streaming data
[edit] Ease of implementation
- Implementation of protocol - Most modern toolkits support automated service generation from a WSDL document. SOAP frameworks support processing of SOAP requests and responces.
- Implementation of implied functionality - Clear requirements and drive out abiguity in the specification.
- Using toolkits based on standards to support interoperability.
[edit] Security
- Transmission of capability information
- Data encryption
- Add the concept of Universal Identifiers for customers, properties and transactions. (Future)
- Include or at least allow for:
- Single sign-on (SSO) facilities (Future)
- Digital rights
- eSignature
- digital signatures.
- Security Policy Document – SAML (Future)
- Closely follow W3C WS-Security.
- "Security in a Web Services World: A Proposed Architecture and Roadmap"-http://www-106.ibm.com/developerworks/library/ws-secmap/
- XML Key Management (W3C)
- XML Signatures (W3C)
- XML Encryption (W3C)
- SAML (Oasis)
[edit] Data
Add greater support for data needed to perform important real estate business processes in support of the overall transaction (beyond listing data)
- Replace monolithic STANDARD-XML and extend the CUSTOM-XML concept to use a combination of smaller primary and secondary schemas for specific data sets.
- Separate bulk-download, point-to-point data replication from small end-user query transactions.
- Make use of XML namespaces.
- Explore Transaction Types to Support
- Leverage RETS Object Model
- Transaction type support matrix (common requests/common responses)
- Make sorting available. (Future-TBD)
[edit] Interoperability with Other Standards
- W3C, Oasis, WS-Interoperability
- Direct interoperability - Large-scale interoperability requires shared semantics, i.e. standard names.
- Conformance to requirements for partnership/submission to higher standards bodies (OASIS, OSRCE, MISMO)
- Support Business Rules for Policy and validation concerns (Future)
- Closely follow the many W3C and Oasis WS standards; e.g. RDF, OWL Format (DTD): XML Schema , maybe Schematron, Relax NG , XSQL Query: XPath 2.0, XQuery 1.0
- Keep especially close eye on WS-Interoperability as standards included there are most interoperable
- Look into alternatives to RETS proprietary solutions in favor of accepted standard for same functionality; e.g.
- Replace DMQL with more standards-based language (RQL)
- Evaluate client use of 1.x Metadata vs. a discovery service - Maybe WS-MEX, UDDI, RDFS or OWL (may not be reasonable – not enough functionality)
