add etch proposal
adding Yonik as a nominated mentor
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|= Abstract||== Abstract ==|
|Line 5:||Line 5:|
|= Proposal||== Proposal ==|
|Line 9:||Line 9:|
|= Background||== Background ==|
|Line 13:||Line 13:|
|= Rationale||== Rationale ==|
|Line 16:||Line 16:|
SOAP/Web Services offer an interesting comparison by contrast. While Web Services are generally accepted as the de facto standard for cross-platform communication due to strong adoption across many tools and languages, the unfortunate reality is that Web Services have serious deficiencies which make them unsuitable for real-time communications. Specifically, Web Services have no effective way to communicate asynchronously from server to client due to a reliance on HTTP and have very high parsing overhead due to XML message bodies. Furthermore, in some deployments, server-to-client communications are blocked by firewalls. Finally, given any two languages, it is not likely that they both support every aspect of Web Services identically, so it is completely possible to create a Web Service that is not, in fact, cross platform, or language agnostic.
|Line 25:||Line 23:|
|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.( This is just an observation. 4 paragraphs to make your point about how difficult it is for developers of network-centered service. Now, maybe that is appropriate to the audience? You decide.)||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.|
|Line 39:||Line 37:|
|= Current Status||== Current Status ==|
|Line 41:||Line 39:|
|== Meritocracy||=== Meritocracy ===|
|Line 45:||Line 43:|
|== Community||=== Community ===|
|Line 49:||Line 47:|
|== Core Developers||=== Core Developers ===
|Line 53:||Line 52:|
|== Alignment||=== Alignment ===|
|Line 57:||Line 56:|
|= Known Risks||== Known Risks ==|
|Line 59:||Line 58:|
|== Orphaned Products||=== Orphaned Products ===|
|Line 67:||Line 66:|
|== Inexperience with Open Source||=== Inexperience with Open Source ===|
|Line 71:||Line 70:|
|== Homogeneous Developers||=== Homogeneous Developers ===|
|Line 77:||Line 76:|
|== Reliance on Salaried Developers||=== Reliance on Salaried Developers ===|
|Line 79:||Line 78:|
|It is expected that Etch development will be done both on salaried time and volunteer time. Cisco is committed as a corporate contributor to continue to allow Etch development, particularly in light of Etch's key role as an enabling technology of Unified Communications products. It is also expected that non-Cisco developers will become interested in Etch.||It is expected that Etch development will be done both on salaried time and volunteer time. Cisco is highly interested in the success and development of an Etch community. At this time, Etch is a core component of shipping Cisco products and is likely to grow over time. Cisco in interested in investing time to support Etch development and use it as a key component in multiple products. It is also expected that non-Cisco developers will become interested in Etch.|
|Line 81:||Line 80:|
|== Relationships with Other Apache Products||=== Relationships with Other Apache Products ===|
|Line 87:||Line 86:|
|== A Excessive Fascination with the Apache Brand||=== A Excessive Fascination with the Apache Brand ===|
|Line 95:||Line 94:|
|= Documentation||== Documentation ==|
|Line 97:||Line 96:|
|No public documents are available yet. All documentation will be released with the publishing of the source.||Public documents are available. All documentation can be found here http://developer.cisco.com/web/cuae/etch .|
|Line 99:||Line 98:|
|= Initial Source||== Initial Source ==|
|Line 110:||Line 109:|
|= Source and Intellectual Property Submission Plan||== Source and Intellectual Property Submission Plan ==|
|Line 114:||Line 113:|
|= External Dependencies||== External Dependencies ==|
|Line 124:||Line 123:|
|= Cryptography||== Cryptography ==|
|Line 128:||Line 127:|
|= Required Resources||== Required Resources ==|
|Line 130:||Line 129:|
|== Mailing Lists||=== Mailing Lists ===|
|Line 137:||Line 136:|
|== Subversion Directory||=== Subversion Directory ===|
|Line 141:||Line 140:|
|== Issue Tracking||=== Issue Tracking ===|
|Line 145:||Line 144:|
|== Other Resources||=== Other Resources ===|
|Line 149:||Line 148:|
|= Initial Committers||== Initial Committers ==|
|Line 153:||Line 152:|
|Line 154:||Line 154:|
|Line 155:||Line 156:|
|Line 156:||Line 158:|
|Line 157:||Line 160:|
|Line 158:||Line 162:|
|Line 159:||Line 164:|
|Line 160:||Line 166:|
|Line 161:||Line 168:|
|Line 162:||Line 170:|
|Line 163:||Line 172:|
|Shawn Dempsay shawn at dempsay dot com||
Shawn Dempsay shawn at dempsay dot org
|Line 165:||Line 176:|
|Line 167:||Line 179:|
|== Affiliations||=== Affiliations ===|
|Line 169:||Line 181:|
|All the initial committers are Cisco employees.||All the initial committers are Cisco employees, with the exception of Shawn. Shawn left Cisco a couple of weeks ago.|
|Line 171:||Line 183:|
|= Sponsors||== Sponsors ==|
|Line 173:||Line 185:|
|== Champion||=== Champion ===|
|Line 175:||Line 187:|
|We need a hero!||Niclas Hedhman (has offered to be Champion)|
|Line 177:||Line 189:|
|== Nominated Mentors||=== Nominated Mentors ===|
|Line 179:||Line 191:|
|Accepting Applications!||Niclas Hedhman|
|Line 181:||Line 193:|
|== Sponsoring Entity||Doug Cutting|
|Line 183:||Line 195:|
|Accepting Applications!||Yonik Seely
=== Sponsoring Entity ===
Etch is a cross-platform, language- and transport-independent framework for building and consuming network services.
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.
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.
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 proprietary service protocol. This is also burdensome to the developer because now two or more distinct technologies must be used to expose the same interface. This typically means the development and maintenance of parallel implementations of the service using the technologies native to the transport mechanism. Often the result here is that one interface is the complete interface, while others suffer from various levels of partial or out-of-sync implementation.
As a language and transport independent network API generator, Etch can provide programmers with a consistent API model to program against while giving them the ability to redeploy into a variety of languages or transports at runtime (per developer/customer choice). So, one may use the same API implementation to send messages using an XML coding on a stream protocol in Java, or binary coding wrapped in reliable UDP in C#, or a shared memory queue on a router backplane in C, or even Python over SOAP. One could, in fact, support all at the same time, and any others that you care to implement or find, as long as you support the required semantics of the API.
It all comes down to this: developers should not have to care about the implementation language or platform of the service nor what the transport is to get there, as long as basic semantics are honored, and these should be no more or less than the semantics of your programming language of choice. Further, a user requirement about specific protocols should not require rewriting of application logic to make it fit into some arbitrary framework scheme or container.
Etch solves problems lots of projects have. Any project that has a need to define multiple services in a consistent way, or expose services on the network to a variety of languages or platforms can benefit from Etch as technology.
The core developers are all listed in the initial committers list later in this proposal.
The compiler code is in Java, but the technology is language- and protocol-agnostic and suitable for many different projects, including non-Java. The compiler makes use of Apache Ant for orchestrating the build, and Apache Velocity for code generation.
We are all quite committed to Etch and the development of an Etch community. Etch is a core component of shipping Cisco products and will only grow over time.
Our employer is also committed to the success of the technology, allowing us to continue to invest our time in support of Etch development as well as committing to Etch technology as a key component in multiple products.
Etch being orphaned is unlikely.
Inexperience with Open Source
The group of initial committers has had various levels of interaction with open-source communities. Most of us came into Cisco through the acquisition of Metreos in 2006. While at Metreos, Louis Marascio and several of us were active contributor’s to the OpenH323 project. We worked through several bugs, submitted patches and even sponsored development. We have also made contributions to other projects (some accepted, some not) on a much smaller scale over the years, QDox, Maruku, Capistrano, OpenGatekeeper, and Mono.
Etch has been completely developed by Cisco employees, therefore all of the initial committers to the project are affiliated with Cisco.
Etch has just recently been made publicly available. First in binary form in May 2008 as part of a Cisco product and in open source form in July 2008.
Reliance on Salaried Developers
It is expected that Etch development will be done both on salaried time and volunteer time. Cisco is highly interested in the success and development of an Etch community. At this time, Etch is a core component of shipping Cisco products and is likely to grow over time. Cisco in interested in investing time to support Etch development and use it as a key component in multiple products. It is also expected that non-Cisco developers will become interested in Etch.
Relationships with Other Apache Products
Etch currently depends upon these other Apache projects: Velocity, Maven and Ant.
We expect that as Etch becomes available, it will be seen as a very compelling technology and others will begin to depend upon it.
A Excessive Fascination with the Apache Brand
We believe Etch offers much to the Apache brand. We could easily, with the backing of Cisco, take a more independent route and support Etch directly without the Apache foundation. But after much consideration, we truly believe that would be the wrong approach for this technology.
As a technology, we believe Etch is very much a kindred spirit of the other software infrastructure technologies currently part of the Apache community: Ant, Velocity, Derby, and others. The technological niche of Etch--platform and language agnostic service definition and binding-is a technology that can be appreciated across a broad range software domains.
It is our view that Apache is simply the most appropriate community for the kind of technology Etch represents.
Public documents are available. All documentation can be found here http://developer.cisco.com/web/cuae/etch .
Etch has been in development at Cisco since Jan-2007. The system was designed from the beginning to be open-sourced. We consider Etch to be at release 1.0 and ready for production use.
We continue to develop on Etch aggressively and a continually adding tests and documentation to accompany the code, in particular around Etch's unique pluggable architecture.
The compiler and language bindings for Java and C# are working and functional. Etch will be included in shipping Cisco products in Sept-2008 as a core technology component.
Source and Intellectual Property Submission Plan
Apache would receive all source and documentation under the Apache Corporate Contributor agreement. Cisco is the only license holder.
Java, JavaCC and Velocity are core dependencies of the compiler. The Java language binding depends only on Java.
Ant and Maven are used by the build system.
For the other language bindings we have the following compile/link dependencies:
C# - Microsoft .NET v2.0 (Mono compatibility coming soon)
Etch uses the native capabilities of Java and C# to support TLS as an option for the default Etch binary transport protocol.
- JIRA : Etch (ETCH)
Gaurav Sandhir gsandhir at cisco dot com
J.D. Liau jliau at cisco dot com
Hung Nguyen hungng at cisco dot com
James Dixson jadixson at cisco dot com
James deCocq jadecocq at cisco dot com
Louis Marascio lmarasci at cisco dot com
Manoj Ganesan manogane at cisco dot com
Rene Barazza rebarraz at cisco dot com
Rick Bolkey rbolkey at cisco dot com
Scott Comer sccomer at cisco dot com
Seth Call secall at cisco dot com
Shawn Dempsay shawn at dempsay dot org
Shyamali Pease shpease at cisco dot com
Youngjin Park youngjpa at cisco dot com
All the initial committers are Cisco employees, with the exception of Shawn. Shawn left Cisco a couple of weeks ago.
Niclas Hedhman (has offered to be Champion)