Re: [alf-dev] Difference Reports

[Mark Phippard <markp@xxxxxxxxxxxxxxx>]

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. 
_____________________________________________________________________________