bug5627: added AwsShard interface

java/com.sap.sse.landscape.aws/src/com/sap/sse/landscape/aws/AwsShard.java

@@ -0,0 +1,28 @@
+package com.sap.sse.landscape.aws;
+
+import com.sap.sse.landscape.application.Shard;
+
+/**
+ * A shard is represented by a target group that has its own auto-scaling group and which handles a number of sharding
+ * keys.
+ * <p>
+ * 
+ * Technically, the shard's name is represented as a tag value on the {@link #getTargetGroup() target group}, hence the
+ * restrictions for AWS tag values apply.
+ * <p>
+ *
+ * Routing to shards happens at the {@link #getTargetGroup() target group's} {@link TargetGroup#getLoadBalancer() load
+ * balancer}, or more precisely, through the load balancer's HTTPS listener's rule set. Each shard requires a number of rule pairs
+ * of which one rule forwardsrequests based on an HTTP header field requiring the request to be handled by a replica,
+ * and the other one based on the request using the GET request method. Another rule pair is required per three sharding keys
+ * to be handled, due to the restriction on the number of conditions a rule may have.
+ * 
+ * @author Axel Uhl (d043530)
+ *
+ * @param <ShardingKey>
+ */
+public interface AwsShard<ShardingKey> extends Shard<ShardingKey> {
+    TargetGroup<ShardingKey> getTargetGroup();
+    
+    AwsAutoScalingGroup getAutoScalingGroup();
+}

java/com.sap.sse.landscape/src/com/sap/sse/landscape/application/Shard.java

@@ -1,17 +1,27 @@
 package com.sap.sse.landscape.application;
 
+import com.sap.sse.common.Named;
+
 /**
  * Part of a {@link Scope}. A {@link Shard} cannot be moved in isolation and can hence not move across {@link Scope}s.
  * Sharding can be used to optionally split {@link ApplicationProcess}es in groups, each of which being responsible
  * primarily only for a subset of the {@link Shard}s available in the {@link ApplicationReplicaSet}. While we assume
  * that all {@link ApplicationProcess}es in an {@link ApplicationReplicaSet} <em>can</em> handle requests for all
- * {@link Shard}s managed by the replica set, it may be beneficial performance-wise to have individual processes
- * focus only on a subset of {@link Shard}s. This may, e.g., result in better cache utilization and hence less CPU
- * consumption on the hosts running those processes.
+ * {@link Shard}s managed by the replica set, it may be beneficial performance-wise to have individual processes focus
+ * only on a subset of {@link Shard}s. This may, e.g., result in better cache utilization and hence less CPU consumption
+ * on the hosts running those processes.
+ * <p>
+ * 
+ * There may be restrictions for the {@link Named#getName() name} that a shard can have, for example it could be
+ * possible that shard names with quotes or bracked in them are not permitted; the name is expected to be human-readable
+ * and meaningful.
  * 
  * @author Axel Uhl (D043530)
  *
  */
-public interface Shard<ShardingKey> {
-    ShardingKey getKey();
+public interface Shard<ShardingKey> extends Named {
+    /**
+     * @return the keys handled by this shard
+     */
+    Iterable<ShardingKey> getKeys();
 }