Yes that was the paragraph I was referring to. Paul
On Fri, Aug 1, 2008 at 9:29 PM, James Dixson <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >>> This a proposal to enter Etch in to the incubator. >>> >>> See http://wiki.apache.org/incubator/EtchProposal 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: 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 >>> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- > James Dixson > Manager, Software Development > CUAE Engineering, Cisco Systems > (e) [EMAIL PROTECTED] > (p) 512-336-3305 > (m) 512-968-2116 > > > > --------------------------------------------------------------------- > 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]
