+1 (non-binding) -Edward
On Wed, Aug 27, 2008 at 4:02 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote: > +1 > > Paul > > > On Wed, Aug 27, 2008 at 7:42 AM, ant elder <[EMAIL PROTECTED]> wrote: >> +1 >> >> ...ant >> >> On Mon, Aug 25, 2008 at 7:09 PM, Yonik Seeley <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > > > > -- > Paul Fremantle > Co-Founder and CTO, WSO2 > Apache Synapse PMC Chair > OASIS WS-RX TC Co-chair > > blog: http://pzf.fremantle.org > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Best regards, Edward J. Yoon [EMAIL PROTECTED] http://blog.udanax.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
