[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] Workspace discussion
|
Mark,
I agree that from the ALF perspsctive there is not be much difference as
far as these various "architectures" are concerened and much of the
discussion is not necessarily relavent to vocabularies.
So long the essential question is addressed...
How do the files get from the SCM to the tool (and vice versa) under the
control of ALF but without passing through the BPEL engine, without the
SCM knowing before hand which tool needs the files or its location, and
without requiring the tool to integrate with a particular SCM.
then ALF doesn't care if its calling a wrapped client or a wrapped
server. A wrapped client is a server to ALF.
It seem to me that, practically, there is only one solution - Alf
defines a "workspace" service that the SCM implements. This service
"gets" files to a location that is in the same file space as the tool.
ALF can communicate the location of the materialized files by passing a
file path identifier between the services. This identifier is opaque to
ALF. Whether the SCM chooses to implement this service on its server and
calling an agent running in the file context of the tool or by wrapping
its client and deploying it in the same file context at the tool is up
the to SCM service implmentation. The requirement that there be a
commonly accessible file space remains and must be addressed in either
case.
Generally we do not care about multiple endpoints from a vocabulary
perspective except that it is a design and configuration issue for the
service flow.
In the wrapped client case we need to associate the SCM service with the
tool and configure appropriately. We already assume service endpoints
must be patched up at deployment so this should be normal. However
knowing which SCM service is associated with which tool service at
deployment time could be a challenge and may require some extra
infrastructure.
In the wrapped server with agent case we need to communicate the tool
location to the SCM somehow. Ideally the tools actual "location" is not
known until deployment time or later. This may require some extra
infrastructure
So both add potential configuration issues that have may have design
time impact in slightly different ways. This is unfortunate since it
does discount the opportunity for direct replaceability - a stretch goal
for ALF vocabularies but its close enough that we could get
replacibility with a small amount of work.
Tim
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mark Phippard
Sent: Wednesday, June 07, 2006 9:48 AM
To: ALF Developer Mailing List
Subject: Re: [alf-dev] Workspace discussion
alf-dev-bounces@xxxxxxxxxxx wrote on 06/07/2006 11:18:28 AM:
> In the case of SCM, where and how many services are running would
> ultimately be based on the capability of the SCM tool. If the tool
> requires physical access to the disk to manage a workspace, you would
need
> to run the service on whatever physical systems you wanted to touch
> with
> an ALF service flow. If the tool has its own "agents" already in
> place that allow it to update systems "indirectly" then you would
> likely only need one service.
Richard,
Re-reading both of our posts a few times, I actually think that our
architectures are very similar. I think the only difference is that you
envision the SCM server adding functionality that, at least in the case
of Subversion, I intend to push back to the service flows and the
implementation. In other words, someone using my tool, in their service
flow, will invoke my service on the system where they need the code to
go.
Someone using your tool, when building a service flow, might direct
them all to a single server. From an ALF standpoint there is no
difference. To support your needs, it does mean that the workspace
"object" will need to contain information like host name and path, where
as my implementation would "discard" the host name and just use the
path. Or maybe the BPEL engine would use the host name to know where to
invoke my service. In either case, I still think this is all the same
architecture with just differences in how it is deployed.
To everyone in the SCM Vocabulary Group:
I would STONGLY encourage you to re-read the ALF Archtecture document:
http://www.eclipse.org/alf/includes/ALFArchitectureDraft-v00-07.pdf
If you are at all like me, you probably read this weeks/months ago when
you were first learning ALF and a lot of this did not make sense. There
is a lot in that document that clarifies things we have been talking
about. I just re-read it today and it made a lot more sense to me and
helped frame our discussions. I think it would also do a good job in
reminding us what exactly a "Vocabulary" is and what we are doing. I
think we are getting off-track and talking about things that are not
needed to define a vocabulary.
In the same vein, I had also forgotten that there is a very nicely done
document with use-cases:
http://www.eclipse.org/alf/includes/ALFALMUseCases.pdf
And there is also a Requirements document:
http://www.eclipse.org/alf/includes/ALFRequirements.pdf
The requirements document is more about the event manager code and those
aspects of ALF, but still has some relevance.
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.
