The Dispatcher dispatches inbound messages to the correct
process instances and thus has to maintain a store for them. A
ProcessInstance is composed of a BPELProcess and
a ProcessContext. Whereas there exists only one instance of
the BPELProcess per deployed BPEL process, there exists a
multitude of ProcessContext instances, as a new
ProcessContext is created for each client that starts a
process. Hence it makes sense to store the two objects separately.
bexee uses the Data Access Object (DAO) pattern to encapsulate all
access to the BPELProcess and ProcessContext
by providing a DAO for each one of them. The DAO manages the connection
with the data source to obtain and store data.
The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, a File System or any other data source you can think of. The components that rely on the DAO use the simpler interface exposed by the DAO. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source.
In the current version of bexee only an in-memory DAO is provided. In- memory means that data is only stored in memory and hence lost on server restarts etc.
Obviously this might not be enough for most applications and thus bexee provides the flexibility of adding new DAO implementations at a later time without having to modify code.
This flexibility is achieved by using the Abstract Factory pattern as suggested in 'Design Patterns: Elements of Reusable Object-Oriented Software [GoF]'.
In this case, an abstract DAO factory object (Abstract Factory) is provided, which can construct various types of concrete DAO factories, each factory supporting a different type of persistent storage implementation. Once you obtain the concrete DAO factory for a specific implementation, you use it to produce DAOs supported and implemented in that implementation.
The class diagram for the currently implemented DAOs in bexee shows a
base DAO factory (DAOFactory), which is an abstract class
that is inherited and implemented by different concrete DAO factories to
support storage implementation-specific access.
The client can obtain a concrete DAO factory (e.g.
MemoryDAOFactory) by calling the DAO factory's
getInstance() method. Which DAOFactory
implementation will be returned, is determined by an application or
system property (bexee.dao.factory) specifying the fully
qualified class name of the DAOFactory implementation to be
used.
If you are interested in extending the model and writing your own store implementation, take at look at Implementing DAOs section in the Developer's Guide.
For more information on the DAO pattern, please refer to Sun's Core J2EE Pattern Catalog.
