I’m pleased to announce the launch of REST-*.org (http://rest-star.org).  REST-*.org is dedicated to bringing the architecture of the Web to traditional middleware services.  While REST has gained huge momentum in the SOA community, there hasn’t been a lot of standardization of traditional middleware services. The REST-* community aims to introduce new REST-based standards for these traditional services where none exist and provide well-defined guidelines where protocols do exist.

Architecturally we aim to be lightweight and pragmatic with a heavy emphasis on avoiding envelope formats and leveraging the full capabilities of the HTTP protocol.  From a community point of view, we have a totally open process and open source IP.  Anybody can contribute and join the fun.

We’re starting off with two specifications: Transactions and Messaging.  We’ll be expanding it to other areas as the community permits.

Mark Little defined an initial design of RESTful transactions 8 years ago at HP of both 2pc, ACID model as well as a forward-compensation engine.  Michael Musgrove recently used RESTEasy to implement this for the JBoss Transaction Manager.  Some consider REST + Transactions an oxymoron but there are some systems that may require a two-phase-commit protocol.  Compensating Transactions though fit quite nicely in the RESTful paradigm as in the end a TM is really just a coordination service.

For messaging we’re building off of the ideas of both JBoss and others in the open source community.  While Atom has become a popular mechanism for pub/sub in the REST community, it is dependent on an envelope format and was really meant for publishing blogs.  We feel that something simpler is needed to satisify the variety of data formats exchanged between intra and inter business machine-based applications.

Both of these specifications are very raw right now.  We feel that launching with something that is incomplete will allow us to build a set of contributors that have a vested interest in the specifications.

Why are we doing this?

The thing is SOAP has failed as an interoperability protocol. It is too complex to implement both from a vendor point of view and from an application point of view.  Yet, the REST world still lacks many of the core services that enterprise developers have grown accustomed to (rightly or wrongly).  REST-*.org will attempt to fill in the gaps.

Is this vendor driven?

Yes, Red Hat is a vendor.  Yes, we want big vendors to get involved as this will help out with adoption.  But all REST-* specifications are and will be run using open source processes. This means anybody can participate.  Yes, the organization will have to have some structure.

How will we avoid the mistakes of SOAP and WS-*?

Blind idealism.  😉  Red Hat has a good track record for developing software that is community and user driven and then bringing these efforts to standards bodies (Hibernate and Seam are great examples of this).  In this case though, we will be the ones jumpstarting and founding the standards body itself.  We are battle tested in specifications efforts at the JCP and other bodies.  We’ve often been frustrated by the closed and inflexible attributes of these organizations.  We feel our open source roots and ideals make us an excellent candidate to drive and host standardization efforts.