On the RETS standard, a review.

John Bigelow of SOA software had conducted a study of RETS.
One particularly interesting slide says the following:

Conflict amongst members with regard to RETS 1.x vs. 2.x:
Does 1.x work the way it was intended?
Hold off on 2.x or keep going?

Key findings:
1.x, while well on the way to becoming a standard, is not yet ready:
Needs to more efficiently transfer MLS data
Needs to be easier and less resource-intensive to implement
Limited industry adoption 
Majority want efforts to be focused on getting 1.x to a true standard status

His PPT is here.

April 19, 2007 in RETS | Permalink | Comments (1) | TrackBack (0)

RETS Governance: Whoa, Go Mark

Mark Lesswing took the bull by the horns enacted Roberts Rules, and set forth a motion to publicly define a Governance group to get the governance for RETS going again. It has been an off again on  again topic of discussion, and frankly its needed. During the meeting, Mark did name names, and set the committee to create a governance proposal by the August meeting that will be in Chicago.

• Michael Wurzer
• Gregg Petch
• Matthew McGuire
• Peter Spicer
• Mark Lesswing

Were among the designees. Mark was given latitude to expand the group on an as needed basis, especially to include other industry members who may not have been present at the meeting today.

Look to the RETS.org site in the next few hours to see the full list. Mark promises to extend that group by the end of the day.

Well played to Mark for taking charge and getting this critical issue underway. We'll be watching.

April 19, 2007 in RETS | Permalink | Comments (0) | TrackBack (0)

RETS Meeting: Upcoming Meetings, Payloads

RETS Membership payloads detail discussion:

1 An in-person meeting is scheduled to coincide with the NAR Midyear convention in Washington DC. A RETS working group will be meeting a MRIS headquarters as they are located close to the Convention location. MRIS will arrange for Bus Transportation of anyone interested in attending the Meeting. It is currently scheduled for Thurs May 17,  from  9-12 -- To continue discussions on RETS2 Payloads. Please RSVP to Paul Stusiak (co - chair at RETS.org )

2. A second meeting will be an in-person meeting at Move offices in West lake Village outside of Los Angeles. This is scheduled for June to focus on the nitty-gritty of the payloads to iron out remaining details. Date is TBD on this meeting and is intended for those folks how are not attending the NAR Midyear or cannot otherwise adjust schedules to attend the May meeting above. If you are interested in attending this meeting please RSVP to Paul Stusiak so they can make the appropriate plans to accommodate the group.

If you plan on attending either of these meeting, please be prepared to participate, bring your working knowledge of the RETS2 payloads specification.

For both meetings, advance notice is requested (RSVP to Paul Stusiak or Gregg Petch for MRIS meeting)

More on RETS.org

April 19, 2007 in RETS | Permalink | Comments (0) | TrackBack (0)

MLS payloads Review - History

The group reviewed the Payloads documents (the XML schemas ) for each of the transactions. The a portion of the discussion is on the ListingHistory payload. Based on the discussion many of the MLS vendors store their histories in a similar manner, but that it does not match the schema. Perhaps the schema is overly complicated. There was a proposal to simplify History to a more basic format, and create an audit format that allows for a more detailed audit trail of the listing, also in a simple format that allows to look back and see changes to the system.

December 7, 2006 in RETS | Permalink | Comments (0) | TrackBack (0)

Reference Implementation for Single-Sign-On

Paul Hethmon from Clareity presented on the beginnings of SSO for Realtors. 

NAR has funded Clareity to create a freely available reference implementation for the Real estate community to implant Single Sign on.

The will create a version in both Java and .net.

In this scenario there is a service provider, who vouches for an identity to another service provider. 

In the reference, they chose NOT to implement SAML 1.1. as it has been superseded by a newer standard, SAML 2.0. SAML 2.0 also offers more use cases, with single logout, etc…

SAML 2.0 is issued by OASIS (http://www.oasis-open.org). All the IP from participating parties in SAML 2.0 have freely released their code. 

The reference kit will use:
 OpenSAML toolkit (from Interenet2) (http://www.internet2.edu/tools/ )

WSE 3.0 (for .net - http://www.microsoft.com/downloads/details.aspx?familyid=018a09fd-3a74-43c5-8ec1-8d789091255d&displaylang=en)

Axis2 (for Java - http://ws.apache.org/axis2/ )

Code writing is underway. Future updates from Clareity will tell us where the code will reside.

December 7, 2006 in RETS | Permalink | Comments (0) | TrackBack (0)

RETS Strategy and Tactics -

RETS2 Strategic Initiatives:

These initiatives will occur over the next several quarters.

1.    Revamp Governance, Workgroups and process. An update on this topic is expected tomorrow.
2.    Sponsor RETS Evangelist Role(s)  This role was recommended at the RETS workgroup in August.  Originally we were going to hire a specialist to deal with adoption issues. In the meantime a study has been commissioned to study a localized area as a sample market. To understand hurdles, barriers to adoption, etc…
3.    Develop RETS Showcase. To help non technical folks understand the purpose and benefit of RETS as a middleware. Mark Lesswing has approved this for 2007 in the NAR budget.

The tactical plan for RETS 2 includes:

• Fund meetings and key leadership participation.
• Fund open source code to accelerate adoption
• Help increase the value of listing info.
• Fund the development of security guidelines for the industry.
• Generalize RETS to an umbrella “meta-standard that can carry other real estate standards, without adopting or endorsing those standards.
• Using the ubiquity of the MLS data, begin to draw in the transaction vendors.
• Allow the transaction vendors to raise the need for a consolidated, centralized security credential source.
• Be prepared to use RETS and NRDS to provides the basis for a centralized solutions as as the market evolves.

The approach

• Develop the annual RES roadmap to define projects and efforts needed ti implement the tactical plan.
• Fund and monitor approved RETS roadmap projects.
• Coordinate those projects with CRT and […] (I missed the other groups mentioned).

2007 Business projects (these are only suggestions)

• NRDS RETS2 server implementation
• RETS2 server for public records.
• New RETS payload
• TMS and MLS download client.
• Compliance site audits.
• WS-Security
• Rules for RETS (the ability to express business rules)
• Domain specific Language for Real estate
• WSDL Mixins

December 7, 2006 | Permalink | Comments (0) | TrackBack (0)

At the RETS Workgroup meeting

I'm at the RETS workgroup meeting in San Diego this week, and I'll be live blogging my notes from the meeting. These are my working notes, and are not guaranteed to be correct! Quote, Cite, or otherwise use them at your own risk.

December 7, 2006 in RETS | Permalink | Comments (0) | TrackBack (0)

RETS2 Security Roadmap

 *** these are my notes, use at your own risk***

Bringin domain experts as needed, every 4 months.
Investigate Single Sign On with SAML using an out-of-band acqusition  of tokens.
 - 12/07 - Investigate WS-TRUST
 - 12/07 - Then with XML Encryption
 - 04/07 - WS-Policy and WS-MetadataExcahgne to discover policy
 - 08/07 - investigate support for WS-Federation

Components of WS-Security we are interested in:
WS-Policy, for security and assertions
WS-Trust, a model for trust relations, one time passwords, etc...
WS-Federation, is a federation of trust services to federtae identity.
WS-MetadataExchange  - Defined a mechanism for retrieving policies.

Currently on .NET 2.0 with WSE supports all of these components. None of the Java frameworks suuport all of them yet. The projected schedules of the frameworks will help the workgroup decide in was order to consider / incorporate components into drafts of the standard. More than one framework needs to support (ideally, both Java and dotNET)

August 3, 2006 | Permalink | Comments (0) | TrackBack (0)

Compliance Workgroup

Compliance Workgroup -- these are my notes from the proceeding of the workgroup, ***use at your own risk***

August 1, 2006. Hosted by Mark Lesswing and Paul Stusiak. At Chicago, IL. At the RETS Meeting 200607 Chicago Illinois

As RETS versions move ahead, do we need to expire support in clients for older servers. In otherwords, of you have a client, can you drop compliance for older servers, to keep their apps manageable.

Previously the RETS group had agreed that a server should support the current version and one-version-back. So in this case a server would support 1.5 and RETS1.7 (even though 1.7 is still draft).  A client need only support one version, whatever they certify against at that point in time. This does not preclude a client from multiple certs, only that the client -- in order to be certified as compliant -- must do so against at least one of the currently supported server versions.

Therefore a client, could change from being 1.5 compliant to 1.7 compliant, without retaining the legacy suuport for 1.5 (unless there is a specific business need to do so, which is outside the scope of what the group would mandate.)

1.7 is Currently in  Draft status, due to outstanding documentation changes. When Bruce Toback died, some of the documents were locked, where only Bruce could get to the doc.  The docs have been ALMOST completely recreated, but it has taken longer than expected to recreate.

Mark's experience is that he has had to write autodetect code (over 1000 lines of code for 8 server vendors) because even though all are compliant, they are compliant in spirit, and there are implementation differences.

The group also suggested the notion that the specification itself can expire. For example, RETS 1.0 is expired. There is no community support for that older version of the standard, and no consideration would be made towards improving / creating compliance test or corrections to the standard. Someone could still  create a server or client to that version, it just could not be certified as compliant.

Compliance Related issues for consideration in the future.

How do you become RETS compliant? How do you find it on the RETS site

When will / How will RETS1.7 get adopted as a formal spec?

What is the process for getting things updated?

Electronic Voting met with some confusion during the last vote (it was done manually, via email). How can we make electronic voting clearer, easier, and more concrete?

After all was said and done, the group established that there needs to be an arbiter or arbitration group that helps get any client/server disagreements on compliance resolved.
***It was suggested that the Governance workgroup, assuming that the governance revisions are accepted (they have not been discussed as of this writing.)***

The gonvernance body is expected in December to begin to put forth new procedures / guidance for compliance.  Any motions passed at this meeting will only continue in force until such time that the new governance (should it be accepted) is out forth.

RETS2 is a "different beast altogether" and there should be no requirement that a new server implementing 2.0 also retroactively support 1.7, as the transport and plumbing mechanisms are different.

August 2, 2006 | Permalink | Comments (0) | TrackBack (0)

RETS 2 reference implementation design concepts

RETS2 Design Concepts
Presented by Paula O'Brien and Jeff Brush of Falcon Technologies, at the RETS Meeting 200607 CHicago Illinois

RETS2 Design - RETS as a Meta-Standard

A standard that deals with other standards.
- Discovery
- Metadata
- Transport
- Mappings

Paula and Jeff worked for Avantia, and during that time, worked to create a RETS2 protoype. They used:

Velocity - a Java based template engine.
    - which can generate XML from templates.
    - used for placeholders for dynamic information
    - References in XML work with a context object from the server

There is nVelocity in .NET
    - Port of the Apache VElocity framework.
    - uses the same template language.

Manifest:
- Opaque data model
- Flexible - determine mimeType from content Type
- content can carry RETS schema, images, ANY type of payload

Uses MTOM for message transport optimization
- MTOM eables a file to be directly written to the network stream by implementing IXmlSerializable
- Attached files are not encoded at all. It is sent as raw bytes across the network.

INterface - SOAP 1,2 - XFire
- Codehaus XFire s an implementaion of the SOAP 1.2 framework.

Integrating RQL
- Using ANTLR and CRT's rql.g
ANTLR can genreate Java anc C# versions of the Parser and Lexer Code.
The ANTLR parser returns a parse tree.

Errors in the reference implementation are handled using SOAP Faults. The engineering work done here showed where the proper placenment of the fault items should be (but the slide went by so fast, I couldn't see exactly where.)


How can you get the reference implentation? get on the RETS-DEV email list (at RETS.org) and all the information will be distributedt that way. (in other words, it needs about 1 weeks more work, before it can see daylight.)

August 2, 2006 | Permalink | Comments (0) | TrackBack (0)