This is the concluding part of a 2 part article. The first part talked about the component coupling that exists with the conventional component technologies, especially with the caller-callee paradigm on which they are based. In this part, we shall see how Xsemble attempts to resolve the problems, towards achieving the well-coveted dream of completely reusable components.

Component Reuse Demo

See below the flow diagram of “Demo3.ETL” demo project included with Xsemble — annotated to highlight the nodes based on the same component with rectangles of same color.

Impressive, isn’t it? That’s the power!

Imagine how having to write so much less code can accelerate your time to market, save money and increase reliability with less testing.

Mechanisms to Achieve Component Reusability

The key is to have the components to be independent of one another and also the environment. Once they are designed that way, they can be reused freely in different situations.

The Xsemble Controller: We Call You with Your Name

Xsemble generates the glue code that orchestrates among the components. (For those who are familiar with the MVC paradigm, the glue code is the C part — the Controller.)

On the other side, the component side code is created by adding business logic to the code template generated by Xsemble. This code template contains the input and output variables, based on the in and out arguments of the components. Populating the input variables correctly is the responsibility of Xsemble; the component programmer needs to think only about how to make use of them to populate the output variables.

The important point here is that each component implementation uses the names in its own name space.

Let’s understand this with the help of the Demo1.Hello project included with Xsemble.

• The node ‘Entry Get Name’ has an out argument ‘name’, and
• The node ‘Say hello’ as an in argument ‘name2display’.

Both these are connected to the data node ‘user name’, and Xsemble glue code will be responsible for passing on the value correctly. Notably, the code snippets in the components underlying these nodes live in their own name spaces, in the sense that:

• The code behind ‘Entry Get Name’ contains a variable ‘name_out’, derived from the out argument name, and
• The code behind ‘Say hello’ contains a variable ‘name2display_in’, derived from its in argument name

Thus, these components can progress independently of one another and there is no coupling.

Parameterizing Components

Xsemble supports defining parameters at the component level, and setting those parameters at the component instance (node) level. Thus, two nodes which are based on the same component may have different values set for the parameter.

One can make use of this concept to smartly parameterize the components so that the parameter values can be used for making small changes to their behavior, instead of having to duplicate the component implementations. In the Demo3.ETL project, this is the key to have the same component power both the ‘Load source’ and ‘Load target’ nodes.

Handling Caller-Callee

Consider a situation where a web page makes a server call. It needs the server side URL to call. Conventionally, this URL is hardcoded in the web page code. Therefore, you will not be able to use the code as it is in another context, where the URL may be different. This hampers the reusability.

This problem may be generalized to inter-layer calls – where a Component is making a call to an external layer. The caller-callee paradigm is inevitable here.

To handle such situations, Xsemble makes available a pre-filled map ‘externalExitpath2urlMap’ in the Component Implementation code. The programmer needs to take the URL from there instead of hardcoding it. When that is done, the coupling goes away. The component may now be used in another situation with a different URL.

On the same lines, another pre-filled map ‘externalOutarg2varnameMap’ contains the mapping of the URL parameter names (or form parameter names) to the argument name recognized by the next component.

Thus, even those situations where the caller-callee relation is a must get handled this way, and the component independence is preserved.

Programming Precautions

Component programmers need to take some simple precautions — to ensure that they are not making implicit use of some shared resources or global variables in their code. If the code of one component makes use of a global variable and depends on it being set by another component prior to that, then that would create a dependency between the components.

There are some other variants of this theme. Java EE allows setting variables in HttpSession (session scope) or HttpServletContext (application scope). Those too, when done implicitly would create the same kind of dependency.

Avoid such situations in your component code. Instead, pass those values explicitly as the data nodes in the Xsemble flow diagram.

Conclusion

With Xsemble you can achieve a high level of code reuse (through component reuse). This is achieved through making the components independent of one another and the environment. Xsemble’s mechanisms of auto-generating the controller that calls the components, the parameterization support, pre-filled maps help in achieving this.

The reuse can reduce your coding / testing effort, accelerate your time to market, reduce expenditure and improve reliability.