incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward J. Yoon" <edwardy...@apache.org>
Subject Re: [VOTE] accept Etch into the Incubator
Date Wed, 27 Aug 2008 11:24:01 GMT
+1 (non-binding)

-Edward

On Wed, Aug 27, 2008 at 4:02 PM, Paul Fremantle <pzfreo@gmail.com> wrote:
> +1
>
> Paul
>
>
> On Wed, Aug 27, 2008 at 7:42 AM, ant elder <ant.elder@gmail.com> wrote:
>> +1
>>
>>   ...ant
>>
>> On Mon, Aug 25, 2008 at 7:09 PM, Yonik Seeley <yonik@apache.org> wrote:
>>
>>> 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 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 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.
>>>
>>> == Documentation ==
>>>
>>> Public documents are available. All documentation can be found here
>>> http://developer.cisco.com/web/cuae/etch .
>>>
>>> == 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: http://developer.cisco.com/web/cuae/etch . 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 ===
>>>
>>>  https://svn.apache.org/repos/asf/incubator/etch
>>>
>>> === 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
>>>
>>> James Dixson        jadixson at cisco dot com
>>>
>>> James deCocq      jadecocq at cisco dot com
>>>
>>> Rene Barazza        rebarraz at cisco dot com
>>>
>>> Scott Comer         sccomer at cisco dot com
>>>
>>> Seth Call           secall at cisco dot com
>>>
>>> Youngjin Park     youngjpa at cisco dot com
>>>
>>> === Affiliations ===
>>>
>>> All the initial committers are Cisco employees.
>>>
>>> == Sponsors ==
>>>
>>> === Champion ===
>>>
>>> Niclas Hedhman (has offered to be Champion)
>>>
>>> === Nominated Mentors ===
>>>
>>> Niclas Hedhman
>>>
>>> Doug Cutting
>>>
>>> Yonik Seeley
>>>
>>> === Sponsoring Entity ===
>>>
>>> Incubator
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Best regards, Edward J. Yoon
edwardyoon@apache.org
http://blog.udanax.org

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message