Skip to main content

The Architecture


 There are two types of beans— stateful and stateless.

The Architecture

 There are two types of beans— stateful and stateless. If you are calling Windward Reports directly from Java, this difference is usually not important. However, if your beans are loaded by the Report Server to be used for reports generated by calls from a client program over the network, then this is usually an important decision.

A single stateless bean instance will be called while creating multiple reports. These multiple calls may be intermixed between reports. For example, it may call the bean twice for report A, once for report B, two more times for report A, then again for report B.

A stateless bean is much more efficient. It works well when all necessary information for the bean is passed in on the call to the bean. For example, the bean RedNegative is stateless because its actions are based on the string passed in to it. Therefore it can handle calls from numerous reports simultaneously.

The calls StatelessBeanProvider.serverSetup() and StatelessBeanProvider.serverTeardown() are only called when a stateless bean is used by the report server. They are not called if a bean is used when directly calling Windward Reports from Java.

A stateful bean will be created when the generation of a single report begins. It will be called for that single report only. Therefore if two reports both need an instance of the same stateful bean at the same time, two objects will be created and each report will use its bean instance. RunningTotal is an example of a stateful bean.

The StatefulBeanProvider methods are called both if the bean is called via the report server and if the bean is used via direct access from Java.

In the case of a direct call from Java, a bean exists only for the life of generating that one report. The bean is viewed in this case as being “owned” by the calling program and after Windward Reports returns the generated report, it will not touch that bean again.

You must always implement either a StatefulBeanProvider or a StatelessBeanProvider. The BeanProviderImpl based classes are provided as a do nothing implementation of each interface, but do not need to be used.

If you need to create a bean based on an existing class of yours, that class should implement the appropriate BeanProvider interface. If your bean does not need to inherit from a class of yours, then you should create your bean as extending from one of the BeanProviderImpl classes.

The Functionality

You have two basic functionalities available in beans. The first is when using a bean in combination with an out or function tag. In these cases, you are passed the text these tags would place in the report, if the bean did not exist. The bean can then change the text and apply some basic formatting to the text.

The out and function methods return a BeanResult object. This object has numerous values that you can set. Any value that is null is ignored upon return. So null is the means by which you state that the field in the ReturnResult is not being set by your bean.

The second is for the if and forEach tags. In this case, the bean can return a true or false value. In the case of the if tag, it overrides the boolean return of the tag. In the case of a forEach, it functions as an early end to the loop.


If you have a tag with a bean=’name’ attribute, then Windward Reports accepts any number of additional attributes in that tag. These additional attributes can then be accessed in the bean via the passed in tag object. In this manner you can have your beans perform differently based on bean defined attributes set in the tag. The RunningTotal bean makes use of this capability.

  • Was this article helpful?