Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [alf-dev] Re: SPI for service flow persistence?

This is an interesting issue. The way the eclipse RCP addresses this issue
is to provide an initial project context, and allow tools participating in
project activity to decorate the project by adding "natures" to the project.
This concept of adaptable/decorated contexts that are visible between tools
sounds like what ALF could use. In addition to providing a datastore for
inflight tasks, it also provides an organizing construct for tool
relationships. 

Perhaps ALF needs an analogue to the Eclipse "Project" that could act as a
container for process definitions, project-specific roles, etc. The concept
has worked well on the client - with some additional tweaking to accomodate
server parallelism it may work well for us, too.

-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]On
Behalf Of Tim Buss
Sent: Friday, September 09, 2005 3:25 PM
To: alf-dev@xxxxxxxxxxx
Subject: [alf-dev] Re: SPI for service flow persistence?


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?
>
>


_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev



The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it. 



Back to the top