Since wiki pages can change, the full text of the proposal needs to be
in the vote thread.
Here is the text of the proposal:
== Abstract ==
Etch is a cross-platform, language- and transport-independent
framework for building and consuming network services.
== Proposal ==
Etch is a cross-platform, language- and transport-independent
framework for building and consuming network services. The Etch
toolset includes a network service description language, a compiler,
and binding libraries for a variety of programming languages. Etch is
also transport-independent, allowing for a variety of different
transports to used based on need and circumstance. The goal of Etch is
to make it simple to define small, focused services that can be easily
accessed, combined, and deployed in a similar manner. Ultimately with
Etch, service development and consumption becomes no more difficult
than library development and consumption.
== Background ==
Etch was started because we wanted to have a way to write a concise,
formal description of the message exchange between a client and a
server, with that message exchange supporting a hefty set of
requirements. The messaging technology should support one-way and
two-way, real-time communication. It should have high performance and
scalability. I should support clients and servers written in different
languages. It should also support clients/servers running in a wide
range of contexts (such as thin web client, embedded device, PC
application, or server). It must support anyone adding new language
bindings and new transports. It should also be fast and small, while
still being flexible enough to satisfy requirements. Finally, it must
be easy to use for developers both implementing and/or consuming the
service.
== Rationale ==
Existing systems were either too slow, hard to use, bloated and/or
proprietary. In any case, none fit our matrix of requirements
perfectly.
Developers of applications that must leverage the capabilities of
network-hosted services have a daunting challenge. They must cobble
together a heterogeneous collection of services that expose different
APIs with different communications technologies just to integrate with
the services, essentially spending a great deal of energy and effort
on just the basics of inter-service communication rather than core
business logic.
So the desired state then is when developing applications that
leverage the capabilities of dispersed and heterogeneous network
services, APIs must be simple, cohesive, and coherent across network
services. APIs should be easy to consume by developers regardless of
the implementation technology of the service used or the domain a
service is being built within- from client-side web applications to
complex real-time server systems. Put simply, developers ideally
should feel that they are developing to a platform.
API development is a much better understood and simpler subject if you
are building those APIs to be run _locally_ on a single machine or
service. Microsoft and Linux centric API developers have the luxury of
the massive assumption that a standard OS is available with a certain
set of features, and the API libraries do not have to take into
account the complexities of APIs that cross machine or OS boundaries.
Developers of network-centered services, rather than OS-centered
services, do not have this luxury; we have a significant set of issues
facing us today because of the fundamental fact that the network is
not a single machine, or a homogeneous set of machines, but a
heterogeneous and widely distributed set of services.
The conventional method for developers of network services today is to
use either a technology specific to the language of preference, RMI
for Java, .NET Remoting for .NET for C#, etc., or if trying to be
language neutral picking a CORBA ORB or a Web Service technology
like SOAP or REST. These choices are fine until the requirements of
the application cannot accept the limitations of the remoting
technology. If the application needs to work on non-Microsoft
platforms, .NET Remoting is out (unless, of course, you can use the
Mono implementation of .NET, but that brings with it other
challenges). If the need is to support access from languages other
than Java, then RMI is out. If the need includes support for
real-time, asynchronous communication, or symmetric two-way
communications, the Web services technologies must also be rejected.
For other classes of applications, there are simply no standard
choices left. The developer is forced to drop down to a network
protocol level and invent a new messaging system for their needs.
Building a protocol by hand is hard; building a messaging system is
also hard. This dramatically increases the barrier to entry for new,
useful applications that leverage network-services.
An orthogonal problem exists when supporting more than one transport
technology is required of the application, e.g. HTTP/SOAP and
HTTP/REST or HTTP/SOAP and a
