We’re onto streaming joints, that last major topic in the course. Let’s first look at basic exclamation topology we started with to see just how far we’ve come. In lesson one we started with a simple TestWordSpout, and while simple these spouts are very useful as you develop storm topologies to test. In the final lesson one program and exercise, we implemented simple exclamation topologies to connect multiple bolts to the same spout. We’re able to simply connect multiple bolts to the same spout, so if we have multiple spouts, linear topologies are simple. We haven’t, however, covered this configuration. How do we connect multiple streams to a single bolt, and process two bolts received from different streams differently, depending on which component produced it? This is the final topic we’ll cover in this course, a process called streaming joints. It would be great in our topology if we could simply use what we know about stream groupings and simply connect them to multiple bolts. Here we have builder.set bolt, bolt 1, then new exclamation bolt with a parallelism of 1 using a shuffle grouping to spout 1, which is the topology I’ve drawn on the left. It would be great if we can simply change our topology from this to this and add a shuffle grouping to spout 2 to make the connection from spout 2 to bolt 1, and storm allows us to do just that. Adding input streams is as simple as method chaining multiple stream groupings, and we will explore this in the next assignment. We will see that if the downstream bolt handles incoming two poles in the exact same way, we’re done. However, what if two poles arriving from different sources are arriving in different forms? Here for example a tuple of a key, and a second tuple coming from the second spout of a key and a value. How does the downstream bolt dynamically handle tuples from different sources? Perhaps with different fields or even different object types in the same locations. The answer is to use the tuple method, getSourceComponent that returns a string with a componentId defined in the topology as the componentId for example spout 1 or spout 2. And finally, once we have the componentId, we can define in our ExclamationBolt file how to dynamically handle different tuple schema using simple code with the executed methods. Such as accessing tuples and processing them differently depending on which spout they came from. In this code, in the exclamation bolt for example, I’m basically check if the component ID here equals spout 1, notice that spout-1 is the component ID I defined in the topology. And if so access spout 1 tuple, here this could be the key, and do some cool stuff. Else if the component equals spout 2 here, access about two components, perhaps the key and the value, and do some other cool stuff. Now, once we have this comp set completed, we can design simple or complex topologies, such as this, or this, or this, or anything else you can imagine. Simply chain together stream groupings, including all groupings and field groupings, on one or more fields, and you can construct real-time processes to fit your needs, let’s see this in action.