incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <>
Subject Re: [PROPOSAL] Etch
Date Fri, 01 Aug 2008 23:31:00 GMT
Yes that was the paragraph I was referring to.


On Fri, Aug 1, 2008 at 9:29 PM, James Dixson <> wrote:
> Paul,
> Are you referring to the "SOAP/Web Services offer an interesting comparison
> ..." paragraph?
> If so, then I agree it is probably redundant to the Etch rationale and I can
> remove it.
> --
> james
> On 8/1/08 12:34 PM, "Paul Fremantle" <> wrote:
>> James
>> I know its popular to bash SOAP at this point, but there are simple
>> factual inaccuracies in your "why not SOAP" section. Rather than argue
>> about the details I'd like to point out that this section is
>> redundant. Do you really feel you need this in there? If you do I'll
>> start listing your inaccuracies.
>> Paul
>> On Thu, Jul 31, 2008 at 5:16 PM, James Dixson <> wrote:
>>> This a proposal to enter Etch in to the incubator.
>>> See for updates.
>>> In particular, we are looking for an interested Champion.
>>> We welcome any and all comments. :-)
>>> --
>>> James Dixson
>>> -----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.
>>> 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.
>>> 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.( 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.)
>>> 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.
>>> What if this was the reality instead: every interface to a network service
>>> could be had via a single, common API technology that 'just works' in every
>>> major language (C#, Java, Python, Ruby, C or even Javascript in a browser).
>>> What if this technology could produce the native stub code needed to do the
>>> networking and message passing (much like Web Services). Then the developer
>>> could concentrate on the business logic of the application or service rather
>>> than the idiosyncrasies of the network plumbing.
>>> 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.
>>> = Current Status
>>> == Meritocracy
>>> Etch was conceived by Scott Comer and Louis Marascio. As Scott finished the
>>> development of the core compiler and first transport implementation, others
>>> have made various contributions to the project: James Dixson and Shawn
>>> Dempsey have worked on the build environment; Manoj Ganesan has worked on a
>>> Ruby binding; James Dixson on the Python binding; and James deCocq on the C
>>> binding; Manoj Ganesan and Gaurav Sandhir did primary work on C# and
>>> maintenance work all around. J.D. Liau has been instrumental in ideas and
>>> maintenance. Hung Nguyen has created the Windows installer using NSIS and
>>> Seth Call is working on a JavaScript binding with JSON transport for thin
>>> clients.
>>> == Community
>>> 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.
>>> == Core Developers
>>> The core developers are all listed in the initial committers list later in
>>> this proposal.
>>> == Alignment
>>> 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.
>>> = Known Risks
>>> == Orphaned Products
>>> 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.
>>> == Homogeneous Developers
>>> 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 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.
>>> == 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.
>>> = Documentation
>>> No public documents are available yet. All documentation will be released
>>> with the publishing of the source.
>>> = Initial Source
>>> 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.
>>> The language bindings for JavaScript, Python and C are in development.
>>> The Etch development home page is currently hosted a Cisco¹s developer
>>> portal: . Full source and binary
>>> distributions are available there including access to our public subversion
>>> repository.
>>> = 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.
>>> = External Dependencies
>>> 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)
>>> = Cryptography
>>> Etch uses the native capabilities of Java and C# to support TLS as an option
>>> for the default Etch binary transport protocol.
>>> = Required Resources
>>> == Mailing Lists
>>>  * etch-private
>>>  * etch-dev
>>>  * etch-commits
>>>  * etch-user
>>> == Subversion Directory
>>> == Issue Tracking
>>>  JIRA : Etch (ETCH)
>>> == Other Resources
>>>  None
>>> = Initial Committers
>>> 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 com
>>> Shyamali Pease      shpease at cisco dot com
>>> Youngjin Park     youngjpa at cisco dot com
>>> == Affiliations
>>> All the initial committers are Cisco employees.
>>> = Sponsors
>>> == Champion
>>> We need a hero!
>>> == Nominated Mentors
>>> Accepting Applications!
>>> == Sponsoring Entity
>>> Accepting Applications!
>>> --
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> --
> James Dixson
> Manager, Software Development
> CUAE Engineering, Cisco Systems
> (e)
> (p) 512-336-3305
> (m) 512-968-2116
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair


"Oxygenating the Web Service Platform",

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message