RE: [alf-dev] SCM Workspace discussion

[Mark Phippard <markp@xxxxxxxxxxxxxxx>]

alf-dev-bounces@xxxxxxxxxxx wrote on 05/25/2006 04:01:49 PM:

> You make some valid points, but I do want to clarify that we are on the 
same
> page about what ALF is about.
> 
> You say: "Only centralized servers that are running builds, tests, 
security
> scans etc. should need this [SCM] service..." 
> 
> I thought we just started with "build" as an example use case, but that 
ALF
> was more general than that. I thought ALF was to provide a framework for
> integrations between any sort of development tool with any other sort of
> development tool. I.e. to turn the N**2 problem of point-to-point
> integrations into a linear problem.
> 
> I can imagine a wide variety of development tools that might want to
> integrate with SCM:
> 
> Build tool <---> SCM    [to update workspaces, ...]
> Issue-tracking tool <--> SCM   [e.g., to ask what change-set goes with a
> given issue...]
> Testing tool <---> SCM [e.g., to populate a test workspace with scripts, 
or
> to checkout/checkin individual tests or test results]
> Requirements management tool <---> SCM [e.g., to version the 
requirements
> docs, or to associate requirements with change-sets that implement them]
> CAD/CAM tool <----> SCM [e.g., to checkin/checkout, or baseline, some 
set of
> design artifacts]
> Etc.
> 
> Some of these may be initiating the request for SCM services from what 
you
> are calling "centralized servers", but other may be initiating the 
request
> for SCM services from what you'd consider a "client machine" (e.g. some 
PC
> on someone's desktop).
> 
> Is this view of ALF not correct?

I think it is hard to answer for some of them, but I will try.

First, some of these operations are just operating on the metadata so a 
single SCM service could handle the requests OK.  No workspace management 
is needed.  For some of the others, I am not sure I understand why the 
user would not just be using an SCM client.  I envisioned ALF as being 
more about automating process in a somewhat headless manner.  Users that 
need to use tools are still going to use the tools.  Which is not to say 
that your scenarios are not interesting. 

For me, thinking about things like this has raised some interesting 
questions/observations:

ALF isn't just about making a web services interface for a variety of 
tools.  If your issue tracking tool is invoking a web service provided by 
your SCM tool, then that is just another form of point to point 
integration.  For this to be "ALF", the issue tracking tool would have to 
raise an ALF Event, which would cause ALF to trigger a service flow, which 
... I am not sure.  How does the information travel back to the issue 
tracking tool?  Does the SCM tool send the result back to ALF which then 
sends it back to the issue tracker by another service?  To me, that 
doesn't sound very conducive to "interactive" UI functions. 

I suspect for ALF, this operation would need to go in reverse.  When code 
is checked-in to an SCM tool, information is sent to ALF as an event.  If 
the user wanted to do something with that data, they would make a service 
flow.  For example, maybe the information is parsed and stored in an issue 
tracker related to the issues that were fixed, build and tests are invoked 
etc...

I do not think there is anything that would preclude a client tool from 
directly raising ALF events to an ALF server, but I typically expected 
this to be more server-based.  Such as whenever an issue is added/changed 
an event is raised to ALF by the server so that a service flow could 
potentially be executed.   When check-ins/labels are made in the SCM tool, 
the server sends an event to ALF.  When a build is completed the results 
are sent to ALF.  When tests are run, the results are sent to ALF.  Etc. 
These tools would all send events to ALF so that service flows could 
potentially be executed.  Of course these service flows would be running 
actions in various tools which might raise more events etc...

I am not sure in this system how a tool raises an event, which will run a 
service and return data all as part of that request.  I think that sort of 
capability could be useful, I am just not clear how that would work.

Mark




























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