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

["Brian Carroll" <BCarroll@xxxxxxxxxx>]

Mark,

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

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.  We have built a number of custom integrations
for the dynamic exchange of data between tools, where simple batch
scripts would not accomplish the task.  Unfortunately, such integrations
tend to be point-to-point.  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 have worked with a number of tools which overlapped in data content.
To keep the tools in sync, I would copy and past from one tool to
another.  And often the tools did not offer a command line interface, or
the callable API's were for different programming languages, so
integration was doable, but more trouble than it was worth.  I view ALF
as a solution to coordinating tools where I need information to be
consistent across tools.

Regards,
Brian


Brian Carroll
Serena Fellow
Serena
(ofc)  (503) 617-2436
(cell)  (503) 318-2017
bcarroll@xxxxxxxxxx 


-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mark Phippard
Sent: Tuesday, March 07, 2006 6:15 AM
To: ALF Developer Mailing List
Subject: [alf-dev] The role of source control in ALF

Watching the POC demo and writing my web service for Subversion made me
really start to question the role of source control in ALF.  I am sure
that there will be cases where having it supported will be useful, and
having a service interface to a source control tool cannot hurt, but I
wonder how well it is really going to work in the real world.  I think
the whole concept of an SOA kind of falls apart if ALL information that
needs to be exchanged cannot be done via the service interface.  In the
case of source control tools, the information that needs to be exchanged
is ultimately the source itself.  Do you eventually envision defining a
vocabulary or whatever, where the source control service would actually
deliver the artifacts via the web service?  That seems like it would be
hard to do and probably be overly resource and network intensive.

If all you can do is send an instruction to a source control tool
telling it to get source to some folder accessible via the web service
that is going to be very limited in how you can deploy and build your
solution and service flows.  Take the POC demo as an example.  You are
doing a GET of the source code so that you can build it, test it and
scan the source for security bugs.  This only works in the POC demo
because all of the services have access to the same location.  How is
ALF going to move beyond that in the real world?  Are users going to
have to have all of their source-related services deployed on the same
server?  It seems like in a real world deployment you are going to wind
up just using the features that are built into OpenMake, or Ant or
whatever build tool is used to let it go get the source from the source
repository and then build it. 

Is there a trick up your sleeve that I am not aware of, or is this
always going to be a real issue?  If it is, then I think we need to
start defining alternate reasons why ALF is going to provide value.  The
problem with the POC demo is that there are probably hundreds of tools
already out there that do the same thing much easier.  The only parts of
that demo that you could not do with a simple Ant script are the parts
related to the issue tracker and even that could be done relatively
easily if the issue tracker had Ant integration.

Thanks

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.