RE: [alf-dev] Difference Reports

["Tim Buss" <TBuss@xxxxxxxxxx>]

I see a number of cases for meta data reports.  This could apply in
principle to any tool particiapating in ALF, not just SCM

1.	The report content is intended for a human reader only
2.	The report content is intended for further processing by some
other tool
3.	The report content is intended for processing in the ALF logic
to futher the Application Lifecycle application

1. Human reader
The report is primarily intended for display and can be considered
opaque to machine processing. Apart form delivering it to appropriate
users there is nothing in the content that is of direct interest to the
ALF integration of any of the participating tools. The main issue is
that the content may be large.  Given this, we want to avoid streaming
it through the BPEL logic and would prefer it be saved to some commonsly
accessible repository (eg networked file share) and passed around by
reference.  In this case ALF does not care about the format of thje
report content bbut needs to arrange for common storage.  It is assume
that the report is read only.  There are some issues about its lifespan
(ie when does it gets deleted) that we may want to consider

2. Tool processing
The report is intended for further processing by other tools.  The main
issue is the the content be in some standard structured format such that
other tools may reasonably process it in useful ways (eg XML conforming
to some expected schema). There is no requirement that the report data
flow through the ALF events or BPEL flows and so the general solution
would be to save it in some commonly accessible repository (eg networked
file share) and pass it around by reference.  The report content may be
large or it may be small.  As a convenience it may be useful to allow
the content to flow through BPEL either from an ALF Event or as service
response if the the ALF programmer can reasonably expect it it always be
small.  This is not required but may be more effective if many small
reports is the norm (I suspect this is not the case).

3. ALF processing
The report content may be used by the ALF service flow logic to initiate
actions.  It may be large or it may be small but generally we would
expect it to be relatively small (ie 10s of rows not 1000s) We may want
to provide safegaurds to ensure that it is never large.  The content
necessarily is structured in XML conforming to some schema.  It may be a
tool specific schema or a common schema but we would prefer it to be a
common schema (defined or addopted as an ALF vocabulary).  A typical
usage would involve looping through and array of structures, making some
decision based on the content of the current structure and taking some
action as a result of that decision.  BPEL is probably not the best tool
for performing this type of logic.  It may be quite hard to program and
not be very efficient.  If this type of action is occasional then it may
be sufficient that it can be done.  If we expect it to be very common
then we may need to pay closer attention to the issue.


1 and 2 require common storage.  2 and 3 require (or at least prefer) a
common format

On the format of the report it can be considered similar to a query
result and I would expect it to be structured as a set of tables (array
of structures) each or which has a set of rows (structure instances).  I
suspect there is prior work we can leverage.

Tim


-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mark Phippard
Sent: Thursday, June 08, 2006 6:55 AM
To: ALF Developer Mailing List
Subject: Re: [alf-dev] Difference Reports

alf-dev-bounces@xxxxxxxxxxx wrote on 06/07/2006 05:25:59 PM:

> We had some discussion at the SCM vocab meeting about diference
reports. 

> I wrote an email that was too long about this, then emailed it to the 
> wrong location. I decided that was a sign and quickly formatted it and

> slapped it up on the wiki. We can take it down later, it isn't linked 
> in

> to anything. It's more readable there than in an email anyway.
> 
> http://wiki.eclipse.org/index.php/ALF/RevisionsHistory

I agree that a difference or activity report is going to be needed.  I
could see a lot of different tools in the chain potentially wanting this
information.  I think the issue is how it is to be designed to work with
ALF.  The ALF Architecture document doesn't really talk about what might
happen within a service flow.  I suppose we would need to look at
WS-BPEL and various BPEL engines to see what the capabilities are.
Based on what I read in the ALF architecture document, however, I would
say it would be atypical for a service flow to initiate a service such
as "Get Activity Report" and then synchronously wait for that service to
pass back a response that contains the report.  Then, even if it did,
what would the BPEL engine do with that data?

It seems more likely that one of the following two scenarios would be
the likely architecture for this feature:

Service flow initiates "Get Activity Report" which runs asynchronous.
When that service finishes, it posts an ALF Event that has some
appropriate event type, and that references the previous service flow.
The ALF Event Manager would then start a new service flow that could
feed this information into other tools that wanted it.  We would want to
define the vocabulary of the event specific data.  This vocabulary could
either be the content of the report, or it could just be some kind of
pointer to a location where the report was stored.

The second scenario, would be similar but instead of sending an ALF
Event when it finishes, the service could have just been handed some
kind of information that directed it to a location to store the report.
This seems similar to the workspace concept we have been discussing.
For things like build tools, I think if the process just produced a
report file in a location accessible to the build tool, then that would
work OK. 
This is because we already have the same issue for the source code, so
the SCM and Build tool are going to have to be able to cooperate on a
disk location regardless.  For other tools like issue trackers, it seems
like having the data contained within the Event would be more flexible,
so I'd lean towards that approach.  I think the main issue would then be
whether the event data could potentially include the file diffs.  That
seems like it could potentially be problematic as the BPEL engine, and
the ALF Event Manager, might not be designed to process messages that
could potentially be many megabytes.

Mark





________________________________________________________________________
_____
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs. 
________________________________________________________________________
_____
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev

**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.