You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@etch.apache.org by bu...@apache.org on 2011/12/07 18:47:04 UTC
svn commit: r799890 [2/2] - in /websites/staging/etch/trunk/content/etch: ./
images/
Added: websites/staging/etch/trunk/content/etch/roadmap-concepts-router.html
==============================================================================
--- websites/staging/etch/trunk/content/etch/roadmap-concepts-router.html (added)
+++ websites/staging/etch/trunk/content/etch/roadmap-concepts-router.html Wed Dec 7 17:47:03 2011
@@ -0,0 +1,159 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "http://www.w3.org/TR/html4/loose.dtd">
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+<html>
+<head>
+ <title></title>
+
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+ <link rel="icon" type="image/png" href="/etch/images/etch-favicon.png"/>
+
+ <link rel="stylesheet" type="text/css" media="screen" href="/etch/css/style.css">
+ <link rel="stylesheet" type="text/css" media="screen" href="/etch/css/code.css">
+</head>
+
+<body>
+
+<div id="page" class="container_16">
+ <div id="header" class="grid_8">
+ <a href="/etch/"><img alt="Apache Incubator Etch" src="/etch/images/etch-logo.png"/></a>
+ <h1>Apache Incubator Etch</h1>
+ </div>
+ <div style="text-align: right; padding: 10px 20px 0px 0px ;">
+ <a href="http://incubator.apache.org"><img alt="Apache Incubator" src="/etch/images/apache-incubator-logo.png"/></a>
+ </div>
+ <div class="clear"></div>
+ <div id="nav" class="grid_3">
+ <h1 id="general">General</h1>
+<ul>
+<li><a href="index.html">Home</a></li>
+<li><a href="downloads.html">Downloads</a></li>
+<li><a href="http://www.apache.org/licenses/LICENSE-2.0">License</a></li>
+</ul>
+<h1 id="community">Community</h1>
+<ul>
+<li><a href="get-involved.html">Get Involved</a></li>
+<li><a href="contributors.html">Who we are</a></li>
+<li><a href="mailinglists.html">Mailing Lists</a></li>
+<li><a href="issue-tracking.html">Bug Tracker</a></li>
+</ul>
+<h1 id="development">Development</h1>
+<ul>
+<li><a href="sources.html">Source Code</a></li>
+<li><a href="getting-started.html">Getting Started</a></li>
+<li><a href="roadmap.html">Project Roadmap</a></li>
+<li><a href="buildserver.html">Buildserver</a></li>
+<li><a href="tools.html">Tools</a></li>
+</ul>
+<h1 id="documentation">Documentation</h1>
+<ul>
+<li><a href="documentation.html">Overview</a></li>
+<li><a href="presentations.html">Presentations</a></li>
+</ul>
+<h1 id="foundation">Foundation</h1>
+<ul>
+<li><a href="http://www.apache.org">ASF</a></li>
+<li><a href="http://incubator.apache.org/">Incubator</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Thanks</a></li>
+<li><a href="http://blogs.apache.org/">Blogs</a></li>
+<li><a href="http://www.apache.org/security/">Security</a></li>
+</ul>
+ </div>
+ <div id="content">
+ <h1 id="etch_router">Etch Router</h1>
+<p>An Etch client may connect to an Etch service to consume APIs that the service provides. The client may have to
+maintain connections to multiple Etch services for the following purposes:</p>
+<ul>
+<li>The client wants to consume multiple set of unique API's, and each set is provided by a different Etch service</li>
+<li>There are multiple Etch services that are providing the same set of API, and the Etch client wants to connect
+to only one of them at a time, and use the others as a backup for high availability purpose.</li>
+</ul>
+<p>To simplify the client side maintenance of multiple service connections, we'll implement a generic Etch service
+component to sit as a middle man between Etch clients and the API providers ( the Etch servers ). Let's call this
+an "Etch Router".</p>
+<h2 id="basics">Basics</h2>
+<p>Basically, an Etch Router itself is an Etch server - it has its own Etch IDL which defines APIs and data types that
+it implements. Any an Etch client who wants to consume API services may connect to the Etch Router - as the router's
+"client" - and then be registered as an "application" in the router. Any an Etch server who wants to expose its API
+to the Etch router's "applications" may also connect to the Etch router - as the router's "client" too - and then be
+registered as the Etch Router's "service plugin".</p>
+<p>At the plugin's registration time, the Etch Router should be able to identify the set of the APIs that the plugin can
+provide for service. A plugin may be registered either as a "singleton" plugin - i.e. the API set that this plugin
+provides is unique within the router, and no other plugin is providing any duplicate API service - or, as a member
+plugin of a plugin group - a plugin group may contain mutiple plugin members which all provide the same set of API
+service and has a fixed strategy in terms of choosing a member for connection, such as failover or round-robin.</p>
+<p>When registering an application, the Etch Router should also be able to identify the set of APIs that the application
+wants to consume - so that it knows whether the currently registered plugins may satisfy the API requirements. The Etch
+Router may map these identified APIs to one or multiple "singleton plugin" or "plugin group"'s that provide the service.
+Then the Etch Router will establish a dedicated client connection to each of the plugin or plugin members for this
+registered application. The Etch router will maintain these connections for the application: when the application shuts down
+its connection to the router, the router will shut down the dedicated connections to the plugins for that application as well.
+When a plugin shuts down its connection to the router, all its associated connections that the router creates for the registered
+applications will be cleaned up and another connection to a plugin member in the same plugin group (if available) will be
+established for each of the applications, and the affected applications will be notified of this change as well.</p>
+<p>On the application side, the Etch Router may be the only Etch server that the application connects to during its life time.
+As long as the initial registration is successful, it may call the Etch router to consume any API that it claims during Etch
+router registration, and doesn't have to know whether those APIs are provided by the same or different plugins, or whether the
+connections to the plugins has been re-mapped down the road.</p>
+<h2 id="implementation_details">Implementation Details</h2>
+<p>A prototype implementation of this Etch-Router has been checked in at <a href="http://svn.apache.org/repos/asf/incubator/etch/branches/router/services/router/">here</a></p>
+<h3 id="the_plugins_folder_in_etch-routers_home_directory">The "plugins" folder in Etch-Router's Home Directory</h3>
+<p>When the Etch-Router (a Java Etch service) is starting up, it tries loading sub-directories under "plugin" folder in its home - the full path name of the "plugins" directory is configurable in the EtchRouter.properties file, by the property named "plugins.root.dir". Each sub-directory under this "plugins" folder is treated as a profile directory of a named "plugin group" - it usually contains two files:</p>
+<ul>
+<li>One XML binding file compiled from a typical service plugin's Etch IDL - this identifies the set of types and API's that the plugin implements.</li>
+<li>
+<p>A properties file named metadata.txt - the content of this file may look like:</p>
+<div class="codehilite"><pre>plugin.group.type=roundrobina
+plugin.member.url.no1=tcp://127.0.0.1:4001
+plugin.member.metadata.no1=location\=LA
+plugin.member.url.no2=tcp://127.0.0.1:4002
+plugin.member.metadata.no2=location\=LA&language\=French
+</pre></div>
+
+
+<p>This file defines the type of plugin group (currently "roundrobin" and "failover" are supported), and the URLs of the plugin members, or the Etch services that are providing API services defined by the XML binding. Additionally, each plugin member's service may also be marked with one or multiple properties via the "plugin.member.metadata.<serviceName>" property.</p>
+</li>
+</ul>
+<p>The Etch-router will create one "plugin-group" object for each sub-directory under "plugins" and map all the methods defined in the directory's XML binding file to this named plugin-group.</p>
+<h3 id="plugin-group_monitor">Plugin-group Monitor</h3>
+<p>While the Etch-router is running, for each plugin-group that it has loaded, the router will monitor the "up and down" status of each plugin member by establishing a client connection to each member service URL defined in the group's metadata.txt file.</p>
+<h3 id="client_connections_and_api_method_mapping">Client Connections and API Method Mapping</h3>
+<p>Any an etch application may connect to the Etch-router service as an ordinary Etch service - it then may consume any an API method defined in any one of the router's plugin-group XML binding file. On the etch-router side, in the transport stack for each application client connection, a special "EtchRouterFilter" is added to intercept each message sent between the client and the service: if the message is a API method call sent from application client, by looking at the message ID, the router will know which plugin-group has the implementation of the method - then it will find out whether a dedicated client connection has been established to a live member service of the mapped plugin-group for the application client connection. If yes, then it will forward this message to that service connection channel, otherwise, it will ask the mapped plugin-group to create a new service connection to one of its live members (here roundrobin or failover strategy may be adopted to decide
which member to choose) and book keep that mapping information for later reference.</p>
+<p>So for each application client connected to the etch-router, the router may book keep several client connections to the plugin member services. When the application client disconnects, the router will clean up the corresponding plugin member connections associated to the application client; when any one of the plugin member connection is down, the router will ask the plugin group to re-establish another connection and maintain it for the same application client.</p>
+ </div>
+ <div class="clear"></div>
+
+
+</div>
+
+<div id="copyright" class="container_16">
+ <p>
+ Copyright © 2010 The Apache Software Foundation, Licensed under
+ the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.
+ <br />
+ Apache and the Apache feather logo are trademarks of The Apache Software Foundation.
+ </p>
+</div>
+
+</body>
+</html>
+
Added: websites/staging/etch/trunk/content/etch/roadmap-service-configuration-idl.etch
==============================================================================
--- websites/staging/etch/trunk/content/etch/roadmap-service-configuration-idl.etch (added)
+++ websites/staging/etch/trunk/content/etch/roadmap-service-configuration-idl.etch Wed Dec 7 17:47:03 2011
@@ -0,0 +1,426 @@
+/* $Id$
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+module org.apache.etch.services.config
+
+/**
+ * Configuration service provides access to configuration data. The data is
+ * modeled as a general tree structure with a root node which might be a scalar
+ * (boolean, int, double, string, Datetime), a List, or a Map. A List is
+ * indexed by int starting at 0, while a Map is indexed by non-empty string,
+ * generally following identifier syntax (case-sensitive, initial alpha then
+ * alphanumeric) but not required to. Each node in this tree is assigned an id.
+ * The id of the root node is null.
+ *
+ * At a given node in the tree, you may navigate up to the parent, down to the
+ * children, get the name, get the path (absolute, from the root), get the value
+ * if a scalar, enumerate the children if a List or Map, test if it is the root,
+ * a List, or a Map.
+ *
+ * This interface is only used to query configuration data, it does not include
+ * a facility to list available configurations, nor to manage configurations. It
+ * also does not include methods to alter existing configuration data, but it
+ * does allow you to subscribe to receive notification of changes.
+ *
+ * Configuration data is organized into separate spaces. The space is called out
+ * by name. You must have authorization to access the named space. There is no
+ * particular meaning to the name outside the interpretation given by the target
+ * service implementation. The configurations might come from a database, a
+ * directory tree of yaml files, etc. For services, anyway, a good idea would be
+ * to use the service name as it appears in the name service directory entry.
+ *
+ * Here is an example use of these interfaces:
+ *
+ * RemoteConfigurationServer server = ConfigurationHelper.newServer( ... );
+ * server._startAndWaitUp( 4000 );
+ * server.loadConfig( "org.apache.etch.services.ns.NameService/titan" );
+ * String host = server.getStringPath( null, "host" );
+ * int port = server.getIntegerPath( null, "port" );
+ *
+ * A path is a string delimited with '/' characters, much like a file system
+ * path. A path which begins with a '/' is absolute and begins at the root.
+ * Otherwise the path is relative to a specified node. The special names '.'
+ * and '..' may be used to refer to the current node and the parent node.
+ * When a path traverses a List, the index in the list is give as an integer in
+ * the path (e.g., /users/1/age). This would refer to the age of the 2nd user
+ * in a list of users. When a path is specified as null or blank, it is the same
+ * as '.'.
+ */
+@Timeout( 30000 )
+service Configuration
+{
+ /**
+ * ConfigurationException is used to report any problem loading a
+ * Configuration.
+ * @param msg a text description of the problem.
+ */
+ exception ConfigurationException( string msg )
+
+ /**
+ * Loads a configuration. Any previous configuration is discarded along
+ * with any subscriptions. Depending upon the configuration service
+ * capabilities, it may be able to monitor the configuration for changes
+ * and automatically load them.
+ * @param name the name of the configuration.
+ * @return the id of the root node.
+ * @throws ConfigurationException if there is any problem.
+ */
+ @Authorize( canLoad, name )
+ object loadConfig( string name )
+ throws ConfigurationException
+
+ /**
+ * Unloads the current configuration if any.
+ */
+ void unloadConfig()
+
+ /**
+ * Tests whether the configuration exists and can be loaded by this user.
+ * @param name the name of the configuration.
+ * @return true if the configuration exists and can be loaded by this user.
+ */
+ boolean canLoad( string name )
+
+ /**
+ * Tests whether a configuration has been loaded.
+ * @return true if a configuration has been loaded.
+ */
+ boolean isLoaded()
+
+ /**
+ * Returns the id of the root node.
+ * @return the id of the root node.
+ */
+ object getRoot()
+
+ /////////////////////
+ // NODE PROPERTIES //
+ /////////////////////
+
+ /**
+ * Gets the parent of a node.
+ * @param id the id of a node.
+ * @return the id of the parent of the node, or null if it is the root.
+ */
+ object getParent( object id )
+
+ /**
+ * Gets the name of a node which is a child of a map or list.
+ * @param id the id of a node.
+ * @return the name of the node. The name is a string if the parent is a
+ * Map or a List, or "" (the empty string) if the value is the root.
+ */
+ string getName( object id )
+
+ /**
+ * Gets the index of a node which is a child of a list.
+ * @param id the id of a node.
+ * @return the index of the node if the parent is a list, or null otherwise.
+ */
+ int getIndex( object id )
+
+ /**
+ * Gets the path of a node.
+ * @param id the id of a node.
+ * @return the concatenation of the names of the ancestors of the node
+ * with "/" between the names.
+ */
+ string getPath( object id )
+
+ /**
+ * Tests whether a node is the root.
+ * @param id the id of a node.
+ * @return true if the node is the root.
+ */
+ boolean isRoot( object id )
+
+ /**
+ * Tests whether a node is a List.
+ * @param id the id of a node.
+ * @return true if the node is a List.
+ */
+ boolean isList( object id )
+
+ /**
+ * Tests whether a node is a Map.
+ * @param id the id of a node.
+ * @return true if the node is a Map.
+ */
+ boolean isMap( object id )
+
+ /**
+ * Gets the number of children of a node which is a List or Map.
+ * @param id the id of a node.
+ * @return the number of children.
+ */
+ int size( object id )
+
+ //////////////
+ // CHILDREN //
+ //////////////
+
+ /**
+ * Lists the ids of the children of a node.
+ * @param id the id of a node.
+ * @param offset index into the result set of the first item to return. If
+ * null, 0 is used.
+ * @param count count of items to return. If null, all remaining items are
+ * returned.
+ * @return array of child ids, or null if the node is a scalar node.
+ */
+ object[] listConfigIds( object id, int offset, int count )
+
+ /**
+ * Lists the ids of the children of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @param offset index into the result set of the first item to return. If
+ * null, 0 is used.
+ * @param count count of items to return. If null, all remaining items are
+ * returned.
+ * @return array of child ids, or null if the node is a scalar node.
+ */
+ object[] listConfigPathIds( object id, string path, int offset, int count )
+
+ /**
+ * Gets the id of a child of a node by index. The node must be a List.
+ * @param id the id of a node.
+ * @param index an index of the child node. Starts at 0.
+ * @return id of the child.
+ */
+ object getConfigIndex( object id, int index )
+
+ /**
+ * Gets the id of a child of a node by path. The nodes along the path must
+ * all be a List or Map except the last. Whenever a path element is being
+ * applied to a list node, it must be an integer.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @return id of the child.
+ */
+ object getConfigPath( object id, string path )
+
+ ////////////////////////
+ // NODE / PATH ACCESS //
+ ////////////////////////
+
+ /**
+ * Tests whether a node has a value.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @return true if the node has a value.
+ */
+ boolean hasValuePath( object id, string path )
+
+ /**
+ * Gets the value value of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @return the value of the node, or null if none. Note that the value may
+ * not be the expected type. That depends upon the underlying
+ * implementation. If you want the value as a specific type, use
+ * getTypePath() methods below.
+ */
+ object getValuePath( object id, string path )
+
+ /**
+ * Gets the boolean value of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @return the value of the node, or null if none.
+ */
+ boolean getBooleanPath( object id, string path )
+
+ /**
+ * Gets the integer value of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @return the value of the node, or null if none.
+ */
+ int getIntegerPath( object id, string path )
+
+ /**
+ * Gets the double value of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @return the value of the node, or null if none.
+ */
+ double getDoublePath( object id, string path )
+
+ /**
+ * Gets the string value of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @return the value of the node, or null if none.
+ */
+ string getStringPath( object id, string path )
+
+ /**
+ * Gets the Datetime value of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @return the value of the node, or null if none.
+ */
+ Datetime getDatePath( object id, string path )
+
+ /**
+ * Gets the List value of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @param depth if any of the values in the list are themselves maps or
+ * lists, recursively get those values too up to the specified depth. Depth
+ * value of 0 means only get the values of the node itself.
+ * @return the List value of the node.
+ */
+ List getListPath( object id, string path, int depth )
+
+ /**
+ * Gets the Map value of a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ * @param depth if any of the values in the map are themselves maps or
+ * lists, recursively get those values too up to the specified depth. Depth
+ * value of 0 means only get the values of the node itself.
+ * @return the Map value of the node.
+ */
+ Map getMapPath( object id, string path, int depth )
+
+ /////////////////
+ // NODE ACCESS //
+ /////////////////
+
+ /**
+ * Tests whether a node has a value.
+ * @param id the id of a node.
+ * @return true if the node has a value.
+ */
+ boolean hasValue( object id )
+
+ /**
+ * Gets the value value of a node.
+ * @param id the id of a node.
+ * @return the value of the node, or null if none. Note that the value may
+ * not be the expected type. That depends upon the underlying
+ * implementation. If you want the value as a specific type, use getType()
+ * methods below.
+ */
+ object getValue( object id )
+
+ /**
+ * Gets the boolean value of a node.
+ * @param id the id of a node.
+ * @return the value of the node, or null if none.
+ */
+ boolean getBoolean( object id )
+
+ /**
+ * Gets the integer value of a node.
+ * @param id the id of a node.
+ * @return the value of the node, or null if none.
+ */
+ int getInteger( object id )
+
+ /**
+ * Gets the double value of a node.
+ * @param id the id of a node.
+ * @return the value of the node, or null if none.
+ */
+ double getDouble( object id )
+
+ /**
+ * Gets the string value of a node.
+ * @param id the id of a node.
+ * @return the value of the node, or null if none.
+ */
+ string getString( object id )
+
+ /**
+ * Gets the Datetime value of a node.
+ * @param id the id of a node.
+ * @return the value of the node, or null if none.
+ */
+ Datetime getDate( object id )
+
+ /**
+ * Gets the List value of a node.
+ * @param id the id of a node.
+ * @param depth if any of the values in the list are themselves maps or
+ * lists, recursively get those values too up to the specified depth. Depth
+ * value of 0 means only get the values of the node itself.
+ * @return the List value of the node.
+ */
+ List getList( object id, int depth )
+
+ /**
+ * Gets the Map value of a node.
+ * @param id the id of a node.
+ * @param depth if any of the values in the map are themselves maps or
+ * lists, recursively get those values too up to the specified depth. Depth
+ * value of 0 means only get the values of the node itself.
+ * @return the Map value of the node.
+ */
+ Map getMap( object id, int depth )
+
+ /////////////////////////
+ // CHANGE NOTIFICATION //
+ /////////////////////////
+
+ /**
+ * Subscribes to changes at or below a node.
+ * @param id the id of a node.
+ */
+ void subscribe( object id )
+
+ /**
+ * Subscribes to changes at or below a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ */
+ void subscribePath( object id, string path )
+
+ /**
+ * Unsubscribes to changes at or below a node.
+ * @param id the id of a node.
+ */
+ void unsubscribe( object id )
+
+ /**
+ * Unsubscribes to changes at or below a node.
+ * @param id the id of a node.
+ * @param path a path relative to the node.
+ */
+ void unsubscribePath( object id, string path )
+
+ /**
+ * Unsubscribes to all changes.
+ */
+ void unsubscribeAll()
+
+ /**
+ * Notifies client of changes to the values of nodes. Added or deleted nodes
+ * are treated as updates to the parent. Reporting is done on a best effort
+ * basis. The nodes reported might be an ancestor of the nodes which
+ * actually changed.
+ * @param updated the ids of nodes that have been updated.
+ */
+ @Direction( Client )
+ @AsyncReceiver( Queued )
+ void configValuesChanged( object[] updated )
+}
Added: websites/staging/etch/trunk/content/etch/roadmap-service-configuration.html
==============================================================================
--- websites/staging/etch/trunk/content/etch/roadmap-service-configuration.html (added)
+++ websites/staging/etch/trunk/content/etch/roadmap-service-configuration.html Wed Dec 7 17:47:03 2011
@@ -0,0 +1,190 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "http://www.w3.org/TR/html4/loose.dtd">
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+<html>
+<head>
+ <title></title>
+
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+ <link rel="icon" type="image/png" href="/etch/images/etch-favicon.png"/>
+
+ <link rel="stylesheet" type="text/css" media="screen" href="/etch/css/style.css">
+ <link rel="stylesheet" type="text/css" media="screen" href="/etch/css/code.css">
+</head>
+
+<body>
+
+<div id="page" class="container_16">
+ <div id="header" class="grid_8">
+ <a href="/etch/"><img alt="Apache Incubator Etch" src="/etch/images/etch-logo.png"/></a>
+ <h1>Apache Incubator Etch</h1>
+ </div>
+ <div style="text-align: right; padding: 10px 20px 0px 0px ;">
+ <a href="http://incubator.apache.org"><img alt="Apache Incubator" src="/etch/images/apache-incubator-logo.png"/></a>
+ </div>
+ <div class="clear"></div>
+ <div id="nav" class="grid_3">
+ <h1 id="general">General</h1>
+<ul>
+<li><a href="index.html">Home</a></li>
+<li><a href="downloads.html">Downloads</a></li>
+<li><a href="http://www.apache.org/licenses/LICENSE-2.0">License</a></li>
+</ul>
+<h1 id="community">Community</h1>
+<ul>
+<li><a href="get-involved.html">Get Involved</a></li>
+<li><a href="contributors.html">Who we are</a></li>
+<li><a href="mailinglists.html">Mailing Lists</a></li>
+<li><a href="issue-tracking.html">Bug Tracker</a></li>
+</ul>
+<h1 id="development">Development</h1>
+<ul>
+<li><a href="sources.html">Source Code</a></li>
+<li><a href="getting-started.html">Getting Started</a></li>
+<li><a href="roadmap.html">Project Roadmap</a></li>
+<li><a href="buildserver.html">Buildserver</a></li>
+<li><a href="tools.html">Tools</a></li>
+</ul>
+<h1 id="documentation">Documentation</h1>
+<ul>
+<li><a href="documentation.html">Overview</a></li>
+<li><a href="presentations.html">Presentations</a></li>
+</ul>
+<h1 id="foundation">Foundation</h1>
+<ul>
+<li><a href="http://www.apache.org">ASF</a></li>
+<li><a href="http://incubator.apache.org/">Incubator</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Thanks</a></li>
+<li><a href="http://blogs.apache.org/">Blogs</a></li>
+<li><a href="http://www.apache.org/security/">Security</a></li>
+</ul>
+ </div>
+ <div id="content">
+ <h1 id="configuration_service">Configuration Service</h1>
+<p>The configuration service (and corresponding local components) allow for remote administration of a service or client. This remote administration is essential for enterprise deployments. The template main programs that etch creates for you have configuration information (service and listener uris) built into the code. If you go too far down this path then your programs will be hard to deploy as they will need to be recompiled to change settings. There is a natural evolutionary path often taken:</p>
+<ul>
+<li>Embedded code</li>
+<li>Command line (or plugin properties)</li>
+<li>Local configuration file</li>
+<li>Remote configuration file or database</li>
+</ul>
+<p>At each level above we are trading off convenience for manageability. The last level is the most manageable for the operators, while the first level is the most convenient for the programmers.</p>
+<p>The best practical systems often use a combination of the above techniques to achieve the goals of the project.</p>
+<p>Another direction taken on configuration is whether the configuration information is static or dynamic. Static information is fixed once the program starts, dynamic configuration can change while the program is running. Consider a running service listener with some configured information for the listener uri and also the names, passwords, and other information for the users. Suppose it is statically configured. Some user information needs to be updated. The service must be stopped, the configuration updated, and the service started again. During that time the service is unavailable, and sometimes work in progress when the service went down is lost. Dynamic configuration would have allowed that service to remain available while the information was being updated.</p>
+<h2 id="requirements">Requirements</h2>
+<p>One of the goals of a configuration service should be to not make things so inconvenient for the programmers that the technique is abandoned. There are several ways that configuration interferes with programmers:</p>
+<ul>
+<li>The act of adding a new configuration item is burdensome.</li>
+<li>Development is hindered by requirement of using an external service.</li>
+<li>Different interfaces for local vs. remote configuration.</li>
+<li>Different interfaces for various languages.</li>
+<li>Parsing and checking configuration values.</li>
+</ul>
+<p>From these we can come up with some requirements:</p>
+<ul>
+<li>Same api for local and remote configuration.</li>
+<li>Same api for various languages.</li>
+<li>Minimal information needed to get started during development.</li>
+<li>Self-contained / standalone development experience.</li>
+<li>Api delivers required data type.</li>
+</ul>
+<p>Some other requirements come from extant ideas for configuration. XML brought us structured documents and this is perfect for configuration information as well. XML makes a lousy configuration medium because it is syntactically complex. Yaml has the advantage of being much simpler and just as powerful. Property files and command lines are initially easy but have no structure and run out of gas fast. Databases are good for structured data but are very complex to setup and use. File systems are nice and have a structured model but are perceived as heavyweight and difficult to manage. Let's go with yaml for a bit and see what we can use. Here's an example yaml file:</p>
+<div class="codehilite"><pre>listenerUri: tcp://realty.net:4001
+users:
+ mary: { birthday: 1959-10-01, zip: 94001, pw: zowie1, active: true, interest: [ home, condo, apartment ] }
+ jake: { birthday: 1967-01-19, zip: 78759, pw: flak33, active: false, interest: [ commercial ] }
+</pre></div>
+
+
+<p>Ok, we can see (or guess) the following:</p>
+<ul>
+<li>Structured organization (scalars, maps, lists)</li>
+<li>Easy syntax</li>
+<li>Simple scalar data types (boolean, integer, real, strings, dates)</li>
+<li>Easily supported in a variety of languages.</li>
+</ul>
+<p>(I'm taking a subset of the possible yaml capabilities, ignoring references and complex language dependent data types.)</p>
+<p>(Note that, while I'm talking about yaml, that I'm using it as a programmer friendly model.)</p>
+<p>The data types supported by yaml match etch capabilities as well. So, let's call these a requirement.</p>
+<ul>
+<li>Data types supported include boolean, integers, reals, strings, dates, maps, sets, and lists.</li>
+</ul>
+<p>In the example above, we see that users is a map with two elements, mary and jake. Mary (and jake) is a map with 5 elements. We can think of maps (and lists and scalars) as nodes in a directed acyclic graph, with maps and lists containing more nodes within and scalars only having values. If I have my finger on the node users, I can reference mary's birthday by using the path "mary/birthday". I could also globally reference jake's password as the path "/users/jake/pw". The second of mary's interests could be referenced as the path "interest/1" with value condo. This naming scheme looks like a file system or network db, and so it is.</p>
+<ul>
+<li>Configuration data is organized into a directed, acyclic graph of nodes. Each node has a unique id and is either a map, a list, or a scalar value. Each node has a single parent. Each node has a unique name relative to its parent, and a unique path of names relative to the root node.</li>
+</ul>
+<p>This allows us to treat subtrees of the configuration data generically, such as the subtrees "users/mary" and "users/jake" which are each "a user". By this abstraction we can write code which maps configuration data onto objects.</p>
+<p>Some generic operations are suggested for nodes:</p>
+<ul>
+<li>getParent, getName, getIndex, getPath, isRoot, isList, isMap, size</li>
+</ul>
+<p>These operations work for all nodes. Given a node id, they return the appropriate property.</p>
+<p>For nodes which are maps or lists, we need to be able to list the children:</p>
+<ul>
+<li>listConfigIds</li>
+</ul>
+<p>Given a node id, lists the children of this node. A node id list is returned.</p>
+<p>For nodes which are maps or lists, we need to be able to get a specific named (or indexed) child:</p>
+<ul>
+<li>getConfigPath, getConfigIndex</li>
+</ul>
+<p>Given a node id and a path or index, gets the node id of the specified child node.</p>
+<p>For nodes which are scalars, we need to be able to get the value:</p>
+<ul>
+<li>hasValue, getBoolean, getInteger, getDouble, getString, getDate, getMap, getList, getSet</li>
+</ul>
+<p>The operation hasValue tests to see if the value is present, the get operations return the value as the requested data type if it is or can be converted to that type.</p>
+<p>For convenience, the value getting operations include three extra methods: getMap, getList, and getSet. These take structural nodes and return them as best effort mappings into local equivalents of the raw underlying data. You lose the data conversion capabilities of the scalar access methods (getBoolean, etc.).</p>
+<h2 id="example">Example</h2>
+<p>Here is a code snippet to access a mary's birthday:</p>
+<div class="codehilite"><pre>java.util.Date bd = service.getDate( service.getConfigPath( service.getRoot(), "users/mary/birthday" ) ) );
+</pre></div>
+
+
+<p>That's a bit of typing, eh? Generally you'd cache the value of root in a variable, and let's add a convenient operation to get a value given a node and a relative path without having to handle the node id ourselves:</p>
+<div class="codehilite"><pre>Object root = service.getRoot();
+...
+java.util.Date bd = service.getDatePath( root, "users/mary/birthday" );
+</pre></div>
+
+
+<h2 id="complete_configuration_idl">Complete Configuration IDL</h2>
+<p>Now, this interface I've defined, it includes only operations to access the configuration values, not change them. I've done it this way on purpose, so that we can quickly get started with a variety of sources and ignore the actual implementation. This interface could, in fact, be implemented in a variety of ways, including file system, network or relational db, property file, yaml file, xml file, command line, or environment variables. Where a particular service supports modification, it would perhaps require a specialized api for that. So, you'd define that api, mixin this basic access api, and that's your service. Clients (of the service) that only need to access the data would use just this basic access api.</p>
+<p>I've not discussed operations relating to noticing updates (however accomplished). I'll catch up to that later. But they are in the access api. Here is a complete etch service <a href="roadmap-service-configuration-idl.etch">idl</a>.</p>
+ </div>
+ <div class="clear"></div>
+
+
+</div>
+
+<div id="copyright" class="container_16">
+ <p>
+ Copyright © 2010 The Apache Software Foundation, Licensed under
+ the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.
+ <br />
+ Apache and the Apache feather logo are trademarks of The Apache Software Foundation.
+ </p>
+</div>
+
+</body>
+</html>
+
Added: websites/staging/etch/trunk/content/etch/roadmap-testing-interoperabillity.html
==============================================================================
--- websites/staging/etch/trunk/content/etch/roadmap-testing-interoperabillity.html (added)
+++ websites/staging/etch/trunk/content/etch/roadmap-testing-interoperabillity.html Wed Dec 7 17:47:03 2011
@@ -0,0 +1,231 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "http://www.w3.org/TR/html4/loose.dtd">
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+<html>
+<head>
+ <title></title>
+
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+ <link rel="icon" type="image/png" href="/etch/images/etch-favicon.png"/>
+
+ <link rel="stylesheet" type="text/css" media="screen" href="/etch/css/style.css">
+ <link rel="stylesheet" type="text/css" media="screen" href="/etch/css/code.css">
+</head>
+
+<body>
+
+<div id="page" class="container_16">
+ <div id="header" class="grid_8">
+ <a href="/etch/"><img alt="Apache Incubator Etch" src="/etch/images/etch-logo.png"/></a>
+ <h1>Apache Incubator Etch</h1>
+ </div>
+ <div style="text-align: right; padding: 10px 20px 0px 0px ;">
+ <a href="http://incubator.apache.org"><img alt="Apache Incubator" src="/etch/images/apache-incubator-logo.png"/></a>
+ </div>
+ <div class="clear"></div>
+ <div id="nav" class="grid_3">
+ <h1 id="general">General</h1>
+<ul>
+<li><a href="index.html">Home</a></li>
+<li><a href="downloads.html">Downloads</a></li>
+<li><a href="http://www.apache.org/licenses/LICENSE-2.0">License</a></li>
+</ul>
+<h1 id="community">Community</h1>
+<ul>
+<li><a href="get-involved.html">Get Involved</a></li>
+<li><a href="contributors.html">Who we are</a></li>
+<li><a href="mailinglists.html">Mailing Lists</a></li>
+<li><a href="issue-tracking.html">Bug Tracker</a></li>
+</ul>
+<h1 id="development">Development</h1>
+<ul>
+<li><a href="sources.html">Source Code</a></li>
+<li><a href="getting-started.html">Getting Started</a></li>
+<li><a href="roadmap.html">Project Roadmap</a></li>
+<li><a href="buildserver.html">Buildserver</a></li>
+<li><a href="tools.html">Tools</a></li>
+</ul>
+<h1 id="documentation">Documentation</h1>
+<ul>
+<li><a href="documentation.html">Overview</a></li>
+<li><a href="presentations.html">Presentations</a></li>
+</ul>
+<h1 id="foundation">Foundation</h1>
+<ul>
+<li><a href="http://www.apache.org">ASF</a></li>
+<li><a href="http://incubator.apache.org/">Incubator</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Thanks</a></li>
+<li><a href="http://blogs.apache.org/">Blogs</a></li>
+<li><a href="http://www.apache.org/security/">Security</a></li>
+</ul>
+ </div>
+ <div id="content">
+ <h1 id="interoperability_testing_framework">Interoperability Testing Framework</h1>
+<p>I've been thinking about this problem for awhile in the context of functional testing. In my group at Cisco a lot of our functional testing is not yet automated because it involves physical devices or complicated server configurations (and multiple servers). We've covered a lot of ground with unit testing, even to the point of a unit test setup which starts a service listener first. We've gotten some nice results with that, but it has its own problems. Mainly, it only works java-to-java and csharp-to-csharp. Plus with both service and client in the same process you get some non-standard interactions. And so I'm ready to take the next step and tackle the problem of automating a unit test which requires some additional server setups in other processes and languages.</p>
+<p>A second issue is, once I have a setup, I want to be able to run it again and again with variations in arguments. This is hard to do within the unit testing framework itself.</p>
+<p>A non-issue for now is automating tests which run on different hosts. So I don't want to do anything that disables that, but I'm not going to try to solve that problem right now. An example is a csharp client running on windows hitting a java server running on linux. So, good idea, we need that, but not today, not now.</p>
+<h3 id="model">Model</h3>
+<p>The model for an interoperability test is to run a test a number of times with different configurations. In a classic etch test, I might run the programs again and again with variations in the urls used to configure the listener and the client. For example, I might run the test with and without the Logger filter, or run the test with both tcp and tls transports.</p>
+<div class="codehilite"><pre>interoptest ::= run*
+
+run ::= test "(" param* ")"
+
+param ::= name "=" value
+name ::= <string>
+value ::= <string>
+</pre></div>
+
+
+<p>The model for a test is setup, support, jig, and cleanup. Each of these is one or more programs which are run. First, the setup programs are run to completion, and perform any required initialization tasks (create required directories or files, init db, etc.). The support programs are then started. They will run for the duration of the test. The jig is a program which is then started and allowed to run to completion. This is best done as a unit test but doesn't have to be. When the jig is up, the support programs are stopped. Finally, the cleanup programs are run to completion, summarizing any test results and cleaning up the mess.</p>
+<div class="codehilite"><pre>test ::= setup* support* jig cleanup*
+
+setup ::= program "(" param* ")"
+support ::= program "(" param* ")"
+jig ::= program "(" param* ")"
+cleanup ::= program "(" param* ")"
+</pre></div>
+
+
+<p>The model for a program is a command line interface. This maps well to both windows and unix operating environments. A program to be run is specified as a series of tokens, the first of which is the program to run, the rest are the command line arguments. Environment variables may also be specified, as well as bindings for stdin, stdout, and stderr. A variation on the theme of binding stdout and stderr is to leave them coming to the console but to tag each line with a text prefix denoting the source. Finally, a timeout may be specified to allow for shutting down a program which gets hung (in this case, the program fails).</p>
+<div class="codehilite"><pre>program ::= token+ env* stdin? stdout? stderr? stdouttag? stderrtag? timeout?
+
+token ::= <string>
+
+env ::= param
+
+stdin ::= filename
+stdout ::= filename
+stderr ::= filename
+
+stdouttag ::= <string>
+stderrtag ::= <string>
+
+filename ::= <string>
+timeout ::= integer
+</pre></div>
+
+
+<p>In this way a program may be defined with whatever inputs and outputs it needs, environment variables, and command line tokens. Then programs may be grouped together to implement a test, and then the tests may be run with variations in parameters.</p>
+<h4 id="example">Example</h4>
+<div class="codehilite"><pre><interoptest>
+ <run test="java-java"/>
+ <run test="csharp-csharp"/>
+ <run test="java-csharp"/>
+ <run test="csharp-java"/>
+
+ <tests>
+ <test name="java-java">
+ <support>
+ <prog name="java_MainPerfListener"/>
+ </support>
+ <jig>
+ <prog name="java_MainPerfClient"/>
+ </jig>
+ </test>
+
+ <test name="csharp-csharp">
+ <support>
+ <prog name="csharp_MainPerfListener"/>
+ </support>
+ <jig>
+ <prog name="csharp_MainPerfClient"/>
+ </jig>
+ </test>
+
+ <test name="java-csharp">
+ <support>
+ <prog name="java_MainPerfListener"/>
+ </support>
+ <jig>
+ <prog name="csharp_MainPerfClient"/>
+ </jig>
+ </test>
+
+ <test name="csharp-java">
+ <support>
+ <prog name="csharp_MainPerfListener"/>
+ </support>
+ <jig>
+ <prog name="java_MainPerfClient"/>
+ </jig>
+ </test>
+ </tests>
+
+ <programs>
+ <program name="java_MainPerfListener">
+ <stdouttag>SOUT</stdouttag>
+ <stderrtag>SERR</stderrtag>
+ <tokens>
+ <token>java</token>
+ <token>-cp</token>
+ <token>../etch/bin</token>
+ <token>etch.examples.perf.MainPerfListener</token>
+ </tokens>
+ </program>
+
+ <program name="java_MainPerfClient">
+ <stdouttag>COUT</stdouttag>
+ <stderrtag>CERR</stderrtag>
+ <tokens>
+ <token>java</token>
+ <token>-cp</token>
+ <token>../etch/bin</token>
+ <token>etch.examples.perf.MainPerfClient</token>
+ </tokens>
+ </program>
+
+ <program name="csharp_MainPerfListener">
+ <stdouttag>SOUT</stdouttag>
+ <stderrtag>SERR</stderrtag>
+ <tokens>
+ <token>../etch/examples/perf/src/main/csharp/PerfListenerProj/bin/Debug/PerfListener.exe</token>
+ </tokens>
+ </program>
+
+ <program name="csharp_MainPerfClient">
+ <stdouttag>SOUT</stdouttag>
+ <stderrtag>SERR</stderrtag>
+ <tokens>
+ <token>../etch/examples/perf/src/main/csharp/PerfClientProj/bin/Debug/PerfClient.exe</token>
+ </tokens>
+ </program>
+ </programs>
+</interoptest>
+</pre></div>
+ </div>
+ <div class="clear"></div>
+
+
+</div>
+
+<div id="copyright" class="container_16">
+ <p>
+ Copyright © 2010 The Apache Software Foundation, Licensed under
+ the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.
+ <br />
+ Apache and the Apache feather logo are trademarks of The Apache Software Foundation.
+ </p>
+</div>
+
+</body>
+</html>
+
Modified: websites/staging/etch/trunk/content/etch/roadmap.html
==============================================================================
--- websites/staging/etch/trunk/content/etch/roadmap.html (original)
+++ websites/staging/etch/trunk/content/etch/roadmap.html Wed Dec 7 17:47:03 2011
@@ -80,7 +80,7 @@
</div>
<div id="content">
<h1 id="project_roadmap">Project Roadmap</h1>
-<p>The Apache Etch system currently includes the compiler, bindings for java and csharp, some documentation, and an ant based build system. Development for Etch cuts across the following categories:</p>
+<p>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:</p>
<ul>
<li>IDL, Toolchain, and Language Bindings</li>
<li>Etch Services, of which there are two types<ul>
@@ -92,6 +92,75 @@
<li>Documentation</li>
</ul>
<p>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.</p>
+<h3 id="idl">IDL</h3>
+<p>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.</p>
+<ul>
+<li>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). </li>
+<li>@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.</li>
+<li>@Deprecated and @Delete annotations on service elements to warn of retirement or retire elements but retain their information for historical reasons.</li>
+<li>Option to mixin statement to change the direction of the mixed in interface. This allows some flexibility in certain deployment styles.</li>
+<li>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.</li>
+</ul>
+<h3 id="compiler">Compiler</h3>
+<ul>
+<li>The internal structure of the compiler could certainly use some love, particularly in the areas of error handling.</li>
+<li>We desperately need some unit testing around the compiler, particularly negative tests (error conditions).</li>
+<li>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.</li>
+<li>Better support for Eclipse, Intelli-J, and Visual Studio would be nice.</li>
+</ul>
+<h3 id="language_bindings">Language Bindings</h3>
+<p>Improve the current language bindings. Add new bindings. </p>
+<h4 id="java">Java</h4>
+<ul>
+<li>Xml tagged data format.</li>
+<li>TlsConnection could use server certificate authentication handshake, client authentication via certificate.</li>
+<li>Message filters (i.e., KeepAlive and PwAuth) need to be robustified.</li>
+<li>Always more unit tests and code coverage.</li>
+<li>Java reference documentation e.g. as javadoc </li>
+</ul>
+<h4 id="csharp">CSharp</h4>
+<ul>
+<li>More or less the same as the Java binding</li>
+</ul>
+<h4 id="c">C</h4>
+<ul>
+<li>More or less the same as the Java binding</li>
+</ul>
+<h4 id="other">Other</h4>
+<ul>
+<li>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.</li>
+</ul>
+<h3 id="architecture">Architecture</h3>
+<p>General aspects how the architecture could be extended and improved.</p>
+<ul>
+<li>More transport layers e.g. for SOAP, JMS, UDP, Jabber, Protocol Buffers.</li>
+<li>Efficient connection handling and support of many simultaneous connections.<br />
+</li>
+<li>Transfer of big message e.g. streams <a href="roadmap-architecture-message-size.html">more</a></li>
+<li>Connection lifecycle management <a href="roadmap-architecture-transport.html">more</a></li>
+</ul>
+<h3 id="concepts_of_application_services">Concepts of Application Services</h3>
+<p>These are proposed services that could be used by any application or service. They abstract common activities through an Etch interface.</p>
+<h4 id="cloud">Cloud</h4>
+<p>Etch Cloud services are services that facilitate the communication between multiple Etch consumers and producers. The following mantra is true for all Etch Cloud:</p>
+<p>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.</p>
+<p>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. <a href="roadmap-concepts-nameservice.html">more</a></p>
+<p>Etch Router Service - Failover, redundancy, policy enforcement, geographic preference... the Etch Router helps Etch clients find just the right Etch service and stay connected. <a href="roadmap-concepts-router.html">more</a></p>
+<h4 id="logging">Logging</h4>
+<p>General purpose network-hosted log catcher</p>
+<h4 id="configuration">Configuration</h4>
+<p>Who needs YAML files, pull your configuration over the network <a href="roadmap-service-configuration.html">more</a></p>
+<h4 id="authentication">Authentication</h4>
+<p>Many services in the web world have single sign on, Etch can too!</p>
+<h3 id="documentation">Documentation</h3>
+<p>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.</p>
+<h3 id="testing">Testing</h3>
+<p>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:</p>
+<ul>
+<li>Validate Suite Framework and Service definition</li>
+<li>Per binding implementation of the validation suite service</li>
+</ul>
+<p><a href="roadmap-testing-interoperabillity.html">Here</a> you can find a discussion on Interoperability Testing Framework.</p>
</div>
<div class="clear"></div>