One form of PRPC Module is the Functional Component. Such components can be expressed as s core objects which provide one or more related actions to clients of the object. They are used to perform well defined computations which avoid changes of state and mutable data. They perform functions rather than make decisions. They are relatively generic. A typical Functional Component will have a purpose and interface which would be familiar to designers of similar data systems inside or outside of the enterprise. Each will tend to support an archetypical set of functions using general purpose parameters.
Identification
Functional Components are used in the applications as means to complete some external directive of the process. They are the implications of the process rather than a functional specification participating in the process. For example, any application involving a calculation process may want to generate an invoice of the same. In this case the invoice generation feature would be identified and implemented as a Functional Component. The external nature of the Functional Component makes it naturally closer to traditional IT/development mindset. These modules are often easily specified and therefore likely targets for remote construction.
Design
Functional Components should be built in a way that makes them analogous to a DLL or Shared Library. The implementation of specific functionality should be abstract and disentwined from the software that leverages them. The class structure used to implement the Functional Component shall be entirely independent of the application’s main class hierarchy but may be related to the class hierarchy of similarly designed Functional Components. The separation of class structures ensures that the usage and the implementation of the functionality are kept independent.
Usage
Functional Components are made available for use in a PRPC application by the inclusion of a containing RuleSet. The infrastructure will interrogate the rulebase at run-time to determine the list of currently available Functional Components. These may be added dynamically or statically; though the invocation of a specifically offered Function on a Functional Component will require some level of design-time introspection to take advantage of it.
Implementation
The implementation of each Functional Component, on the other hand, is free to vary as long as the interface (or signature of the functions) is held constant. The Functional Components will be represented at runtime by a branch of a single high-level clipboard page, and not embedded within the pyWorkPage. Interaction between work objects and Functional Components is accomplished in the same way as that of an interaction between separate, in-process objects.
