[alf-dev] Re: SPI for service flow persistence?

["John Streiff" <john.streiff@xxxxxxxxxxxxxxxxxx>]

This is an inevitable requirement, especially when you have diverse, 
loosely-coupled systems.
I would extend the use case to include the ability to retrieve data from a 
URI-based reference.
This ensures that most any network path can be represented as a storage 
node.
Services handle the details of storing and retrieving persisted data.

As a  real-world example, in our Code Scan technology, we store among other 
things,
results from security analysis runs. We can slice and dice this information 
many ways.
It would be useful for others to query that data at some point after 
successful completion of a
code scan step.

It would also be useful to remember information at various points in the 
process flow.
This is the job of an Event Broker. The Broker can hand it off to another 
service,
but individual services should not have to know or care where the persistent 
storage service is
located in order to use it - the Event Broker provides a facade for the 
physical interface.
An alternative way of doing this of course is using a directory service. 
That detail however
should be hidden from ALF participants in my opinion.

"Kelly Shaw" <kshaw@xxxxxxxxxx> wrote in message 
news:dfnnf1$qj7$1@xxxxxxxxxxxxxxxx...
> I've had a request that we provide a SPI allowing process information to 
> be
> persisted for query later. For the example implementation of ALF this will
> probably mean either a schema definition, a grammar or perhaps a WSDL
> definition for some services that allow data to be CRUD'ed to/from a
> database of some sort. We need not provide the store in ALF, only define 
> an
> interface if a store is to be used.
>
> Are there any comments for/against this approach to service flow info
> persistence?
>
>