Project Roadmap¶

The Apache Etch system currently includes the compiler, bindings for java, csharp and c, some documentation, and an ant based build system. Development for Etch cuts across the following categories:

• IDL, Toolchain, and Language Bindings
• Etch Services, of which there are two types
  • Standard IDL implementations that support service and application development
  • Services that support the Etch Cloud
• Validation and Testing
• Documentation

Some of the projects necessarily cut across the above categories, e.g adding a new transport requires some programming in each binding implementation and documentation, etc.

IDL¶

The Etch language could be extended to include more descriptive information about the service being modeled. We have a few RFE's for extensions, some of which are well-thought out and some of which are sketchy.

• Annotations on message, struct, or exception fields which describe acceptable values. For example, a certain field might be required (not null) and the value within a specified range (e.g., percent: 0-100).
• @AsyncReceiver annotation, while solving a certain problem, forces an implementation which may or may not be necessary. And the lack of the annotation where necessary, causes a headache as the implementor is forced to edit the service description to fix it. Look for a better mechanism.
• @Deprecated and @Delete annotations on service elements to warn of retirement or retire elements but retain their information for historical reasons.
• Option to mixin statement to change the direction of the mixed in interface. This allows some flexibility in certain deployment styles.
• Certain service models, such as REST, include a few standard messages but are heavy on object modeling. Etch data modeling could be strengthened to allow modeling of RESTful api.

Compiler¶

• The internal structure of the compiler could certainly use some love, particularly in the areas of error handling.
• We desperately need some unit testing around the compiler, particularly negative tests (error conditions).
• The build is currently Ant. We're thinking it should be Maven. Maven support for non-java languages is, eh, not all that good. We have an Etch plugin for Ant and sort of Maven. The maven plugin needs to be way better. And having an Etch project archtype for Maven would be nice.
• Better support for Eclipse, Intelli-J, and Visual Studio would be nice.

Language Bindings¶

Improve the current language bindings. Add new bindings.

Java¶

• Xml tagged data format.
• TlsConnection could use server certificate authentication handshake, client authentication via certificate.
• Message filters (i.e., KeepAlive and PwAuth) need to be robustified.
• Always more unit tests and code coverage.
• Java reference documentation e.g. as javadoc

CSharp¶

• More or less the same as the Java binding

C¶

• More or less the same as the Java binding

Other¶

• We have started on Cpp, Ruby, Python, Javascript, and Google Go bindings. Some are more complete than others. I have heard of an Objective C binding. The sources for these are not yet part of standard Etch. We're not sure when or how that will happen.

Architecture¶

General aspects how the architecture could be extended and improved.

• More transport layers e.g. for SOAP, JMS, UDP, Jabber, Protocol Buffers.
• Efficient connection handling and support of many simultaneous connections.
• Transfer of big message e.g. streams more
• Connection lifecycle management more

Concepts of Application Services¶

These are proposed services that could be used by any application or service. They abstract common activities through an Etch interface.

Cloud¶

Etch Cloud services are services that facilitate the communication between multiple Etch consumers and producers. The following mantra is true for all Etch Cloud:

Neither a service (producer) nor application (consumer) should have to be overtly aware of any Etch cloud service. It should be possible to deploy a service or application with or without any supporting Etch cloud services, with no conditional code or changes to code. Etch cloud services are purely deployment time considerations and are not required for operation.

Etch Name Service - Etch URIs can be very long and cumbersome to maintain, the Etch Name Service allows an Etch Service to look-up the necessary connection URI using an abstract reference. more

Etch Router Service - Failover, redundancy, policy enforcement, geographic preference... the Etch Router helps Etch clients find just the right Etch service and stay connected. more

Logging¶

General purpose network-hosted log catcher

Configuration¶

Who needs YAML files, pull your configuration over the network more

Authentication¶

Many services in the web world have single sign on, Etch can too!

Documentation¶

General project infos are documented via this web page. The documentation about the Etch framework and different language binding will be done with Docbook and as HTML and PDF provided.

Testing¶

While the unit tests assure some level of wire format compliance, nothing beats a validation test suite. We need to be able to plug in different (but compatible) transport options and then run a standard set of tests to verify that things still work (while mixing and matching bindings as well). There are two parts to this:

• Validate Suite Framework and Service definition
• Per binding implementation of the validation suite service

Here you can find a discussion on Interoperability Testing Framework.