RE: [alf-dev] The role of source control in ALF

[Mark Phippard <markp@xxxxxxxxxxxxxxx>]

alf-dev-bounces@xxxxxxxxxxx wrote on 03/07/2006 09:42:23 AM:

> One of the main things SCM tools can do in and ALF environment is raise
> events - for example, it may be a significant when a particular file is
> checked in, or a "PRODUCTION" label is applied to a set of files.  So
> SCM tools need to be able to raise ALF events.

Agreed.  And this will definitely be very valuable and allow for some nice 
service flows to be built.

>  We wanted the option to
> keep ALF Events lightweight.  While this is not always possible, in may
> cases, rather than attaching the contents of a source file to an Event,
> you can simply make a reference to the thing that changed.  In fact,
> such references are built into the BasicEvent structure. If a program
> later needs more details about the thing that changed, it can inquire of
> the tool that raised the event.

OK, but whether we are talking about build tools, testing tools, scanners, 
impact analysis etc. these tools are going to need access to the source 
code.  Are these tools going to have to talk directly to the source 
control tool as they always have, or do we envision defining a way to do 
this via an SOA?  And if so how?

> We agree that the POC scenario is rather simple and that particular
> scenario might have been accomplished with various forms of scripting.
> But ALF is intended to coordinate tools that don't necessarily have a
> command line interface. 

Unfortunately, if the POC Demo moves to open source tools, this is one of 
the negative side-effects.  Just about everyone in the open source world 
already has Ant scripts that pull source from CVS, build it, and executes 
the JUnit tests.  In some cases, they also run source scanning tools.  Not 
to mention all of the "continuous integration" tools like CruiseControl 
that do this automatically based on check-ins happening in the source 
repository.

In that sense, the demo is probably more effective when integrating 
commercial tools from different vendors.

> ALF provides the opportunity for all vendors
> to "factor out" that common code that is built into each integration,
> and express the key aspects in BPEL (so that customers) can alter the
> flow.

I agree this is good.  I think the demo is being enhanced to show some of 
these flows.  If so, I think that would be useful.  What would be cool 
would be to take an existing flow that does the build and test, and say 
that you want to enhance it to add the source scanning, and then show 
adding that to the flow.  That could show how easy and powerful the flows 
are, as well as the overall ALF concept.

> I view ALF
> as a solution to coordinating tools where I need information to be
> consistent across tools.

I have written a lot of these integrations as well, including integrating 
with your Dimensions tool.  The problem with these integrations is that 
they tend to solve a very specific problem and can only be customized to 
the extent that was anticipated with they were built.  So they have to be 
constantly tweaked as new customers and requirements surface.  As the ALF 
presentation points out, they also tend to be fragile.  The value I see in 
ALF is in encouraging vendors to provide "building blocks" that the 
customer can then use to build their own integrations using service flows. 
 I think this is going to be very valuable in the long term and should 
provide for a lot richer integration possibilities.  I think it is also 
great for the vendor as it allows them to focus on providing solid 
building blocks for their own products and not worry as much about the 
actual integration aspects as that will be pushed into ALF and the service 
flows.

Mark







_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________