The conecept for Jaffa components is that they have corse grain access into the business logic, which ideally would be stateless. The thinking behind this design is that the business tier may be distributed.

The job of the jaffa middleware is to make the business logic's location and execution transparent to the calling classes. For this reason any program that want to access the business logic (ie a Transaction Controller) does not do so directly, it askes for a class that implements the transaction controller's functionality via the 'middleware factory'.

In an optimized 2 1/2 tier deployment where all code is executing on the Web Server, the middleware will just return and instance of the 'real' trasaction controller. In the case of other deployments, the middleware will return a class that implements the interface, but is only a proxy for calling the real remote transaction controller.

This allows the real transaction controller to be wrappered by RMI, Session EJB, a remote Servlet, a Web Service, etc.

The other feature this provided is the ability to build a 'test' implementation of the business function, that can be used to 'unit test' the presentation tier, without the need for the real business tier. This can be useful if you want to build and test presentation code without needing a working buisness layer for either prototyping the user interface, for unit testing the UI, or if there are seperate teams developing the different tiers, and they are on seperate time frames so the UI team needs something in the interim of the business code being availble.

The jaffa framework can, per component determine which implementation should be used, so you may deploy some functions locally, and some remotely, and have a few others invoking unit tests.