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

["Kelly Shaw" <kshaw@xxxxxxxxxx>]

Providing an SPI would not add persistence to ALF, but would provide a
standard way for persistence to be added by others. Like John, I see this as
an inevitable requirement as ALF progresses.

Data persistence could be handled through web services rather than as an
SPI, but if it is something all production ALF instances will require, and I
suspect it will be, if for no other reason than the need to generate audit
reports, then I suggest we should define the SPI for the following two
reasons.

1. The SPI approach would allow us to define some standard places where
persistence would occur. For example, we could persist the data returned
from web services and link it to the unique event id or to some other unique
id. Then the burden would not have to fall to individual ALF implementations
or individual service flow definitions to persist data.
2. The SPI approach would allow us to define a reporting infrastructure (as
has already been suggested) within ALF, which I see also as an inevitable in
the long-term. Without some understanding of a standard schema, reporting
will also of necessity be something that will have to be completely defined
for each ALF implementation.

We wouldn't necessarily need to do this for our first example
implementation, but with an SPI at least the hooks would be in place.

shaw

"Tim Buss" <tbuss@xxxxxxxxxx> wrote in message
news:dfsnhq$8rk$1@xxxxxxxxxxxxxxxx...
> In general I am wary of this proposal. I am unclear as to what the driving
> requirement is and what advantage we see beyond applications that utilize
> ALF doing this for themselves.
>
> Ideally ALF should only contain that which actually facilitates
> interoperability.  We need to be clear what a Data Persistence SPI would
add
> to ALF interoperability
>
> Some thoughts.
>
> It was deliberate decision that ALF itself will not automatically
accumulate
> instance data.  This is left to the application since only the application
> can know its data storage requirements and deal with any scaling issues
that
> may result.   ALF is not a data storage provider itself outside of any
> persistence it may require for the purposes of configuration, deployment
and
> general operation.  Those things are opaque to an application built on ALF
> and will depend for the most part on the implementation being used (fex.
> which BPEL engine).
>
> One need may be to provide some means around which data may be correlated.
> Data is stored in various tools that ALF coordinates.  This data will be
> identified uniquely by some means specific to the tool that stores it.  It
> seem quite likely that a service flow will need to know that item 1 stored
> in tool A is related to that item 15 stored in that tool B.
>
> I see two ways to address this.
> 1. The tools store the relationship. For example, ALF uses a custom field
on
> Tool A items to store Tool B item IDs. This is "well known" to the system
of
> service flow used by a particular application.
> 2. An application creates a common store that it uses to store
relationships
> and provides services ALF can orchestrate to update and access this data.
>
> Both of these approaches are independent of ALF, and can be used by an
> application as appropriate to its needs.
>
> It may be better to come at this a different way.  For example, what does
> ALF have to say about cross tool reporting?  Should ALF provide some
common
> reporting infrastructure. How might that work?  How would tools
participate?
> Would vendors be likely to support it.
>
> Tim Buss
> Serena Inc.
>
>
> "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?
> >
> >
>
>