RE: [alf-dev] ALF SourceCodeMangementVocabularyMeeting+1-303-928-3232 id

["Tim Buss" <TBuss@xxxxxxxxxx>]

There will be a ALF Source Code Management Vocabulary Meeting this week,
Wednesday Oct 11th at 10:00AM PDT

The call in number is

+1-303-928-3232 id 6053141#

as usual.

Agenda
0. Last meeting's minutes (below)

1. Status on tasks (see list in minutes below)

2. Continue the discussion around T24 "Refine and Normalize Operations
so they work as a coherent set"
(see attached minutes from the special meeting)

3. Any other business


Tim Buss - Serena.        
 

-----Original Message-----
From: Tim Buss 
Sent: Thursday, October 05, 2006 10:58 AM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] ALF
SourceCodeMangementVocabularyMeeting+1-303-928-3232 id
6053141#Wednesday10:00AM PDT - meeting minutes

Meeting minutes for  ALF Source Code Management Vocabulary Meeting this
week, Wednesday Oct 4th at 10:00AM PDT

Attendees:
Mark Phippard
Brian Carrol
Adam Simatel
Robert Reising
Tim Buss

Agenda
0. Last meeting's minutes (below)

1. Status on tasks (see list in minutes below)

2. Discuss issues raised concerning SCM vocab
http://wiki.eclipse.org/index.php/Talk:ALF/SCM_Vocabulary

3. "Callback" idea update

4. Any other business


0. Last weeks Minutes were accepted

1. Status on tasks (see list in minutes below)

Done
T26 Discuss dynamic "Callback" idea
BPEL Correlation was suggested as the way this can be addressed.  See
"Callback" item #3 below.

T30.  POC use case candidates.
We agreed it would be useful to implement one or more POCs based on the
various SCM schemas/WSDLs.  There may be some benefit in trying to do
this before we start any parallel work trying to wrap real products. 
T24 seems important to complete before we start codeing in parallel. 
Adam Simantel has proposed a POC scenario.  See any "other business"
item #4 below 

TODO
T19 Wiki pictures.  There are some placeholders for pictures in the
Wiki.

T24 Refine and Normalize Operations so they work as a coherent set
Assigned to you.
We agreed to a speial meeting set for 10:00am PDT on Oct 9th to focus on
this issue and T29 "return values and faults"

T25 Reflect Operation refinements in Schema and WSDL Assigned to Tim Tim
is waiting for feedback

T27. ALF SCM vocabulary Eclipse WTP "stub" project.
Mark took at look at this and discovered some minor problems with the
SCM WSDL/Schema that need to be fixed.  This task is relatively trivial
soe we are waiting on Task 24,25,29

T28.  Define and prototype "callback mechanism"
BPEL Correlation has been suggested as the mechanism.  Tim Buss work on
a prototype to illustrate this.

T29.  Define return values and faults
(see T24)


2. Discuss issues raised concerning SCM vocab
http://wiki.eclipse.org/index.php/Talk:ALF/SCM_Vocabulary
Thus feedback was reviewed.  We found the object comments to be mostly
terminology.  We will take into account the Use Case feedback as part of
the "Normalization/Refinement discussion"

3. "Callback" idea update
A point was raise that perhaps raising an ALF Event for every
asynchronous action completion may be too heavyweight.  An alternative
using a dynamic callback service passed with the operation was
suggested.  This would probably take the form of an ALF event in
definition but would connect back to the calling instance of the service
flow directly.  The removes the need to create new service flow instance
and simplifies data correlation in some cases.

It is proposed that BPEL correlation should be used to provide this
functionality.  The description below is updated from the original
agenda item clarifying some aspects.

In the BPEL flow definition, you identify message elements that will
identify the BPEL process instance uniquely.  When the BPEL engine
receives a message for a paticular BPEL flow definition it tries to
match it to the various possible entry points to that BPEL process
definition that expect a message of that type.  If the message matches
an entry point that is only active in a running instance of the process
then correlation is used to determine which running instance is
expecting this particular message.  Correlation uses one or more message
element values to match the message to the process instance that is
expecting it.  These values must be defined, initialized and associated
with the entry point (eg <receive>) by the process and they must be also
present in the received message for the match to occur. If the values
match then the message is passed to that running process.

To make this convenient to use, either the service, the service flow or
both parties will need to provide a ID that is unique to the service
flow instance.  The service flow would seem the most likely candidate in
most cases.  There are various options that provide some flexibility as
to what can be used to define the correlation set.  For us it would
probably make sense to come up with some guidelines that make it easy to
support. (eg: one id that is unique per service flow and is structure in
the same place in the same structure wherever it is used.)

Note that it is still necessary for the Service to "callback" to a
specific service flow endpoint.  Since this is dynamic, the endpoint
would have to be passed through the services and either be used by the
tool to invoke the BPEL engine directly or returned in the ALF event to
allow the ALF event manager to invoke the running service flow.  This
latter seem prefereable since it would not change the requirement for
tool participation beyond what is already defined for "ALF compliance".

To work through the event manager, the "callback" would just be an event
and the tool would need to pass through some ALF defined values received
from the Service Flow (ie the endpoint and corellation value(s)) and set
them in the event.  The "callback" entry point <receive> or equivalent
in the BPEL would be defined to take an event message subject to a
correllation with a particular value in the message.  It is unclear if
this indirection is feasible and that would require a prototype.

Another issue is that that while standard, this is fairly "advanced"
BPEL feature and may not be supported by the less mature open source
engines.  ActiveBPEL and Oracle both support it.

A point to be discussed is whether this being a BPEL defined mechanism
binds the Servicefloe implmentation to BPEL.  While this needs some more
thought.  I believe it does not and the mechanism may be generally
applied.  A service would just use the same correlation values to match
the message and since the callback endpoint is dynamic an determined by
the service flow there is no assumption of a BPEL engine endpoint.
Further, it seems possible that the tools may still interact only with
the event manager and are still isolated from the Service Flow
implmentation.

4. Any other business
Adam Simatel proposed a POC scenario.  This is documented in another
email thread. We discussed the proposal and suggested some refinements.
The updated proposal is here
http://wiki.eclipse.org/index.php/ALF/Vocabularies/SCM_Vocabulary/POCUse
Cases

Tim Buss - Serena.        

-----Original Message-----
From: Tim Buss
Sent: Wednesday, September 27, 2006 12:15 PM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] ALF Source
CodeMangementVocabularyMeeting+1-303-928-3232 id 6053141#
Wednesday10:00AM PDT - meeting minutes

Meeting minutes for  ALF Source Code Management Vocabulary Meeting this
week, Wednesday Sept 27th at 10:00AM PDT

Attendees
Adam Simatel
Brian Caroll
Tim Buss
Robert Reising

Agenda
0. Last meetings's minutes (below)

1. Status on tasks (see list in minutes below)

2. Any other business

0. Last meetings's minutes.  Last weeks minutes were accepted

1. Tasks
DONE
T23 Define SCM events XML
Assigned to Tim.  A draft has been presented and is available in the
wiki

TODO
T19
Wiki pictures.  There are some placeholders for pictures in the Wiki.
These need to be populated.  In particular it would be good to get the
updated data model into the Wiki

T24 Refine and Normalize Operations so they work as a coherent set
Assigned to you.  Please provide feedback Richard Title and Adam
Simantel will take a look at this

T25 Reflect Operation refinements in Schema and WSDL Assigned to Tim Tim
is waiting for feedback

T26 Discuss dynamic "Callback" idea
A point was raise that perhaps raising an ALF Event for every
asynchronous action completion may be too heavyweight.  An alternative
using a dynamic callback service passed with the operation was
suggested.  This would probably take the form of an ALF event in
definition but would connect back to the calling instance of the service
flow directly.  The removes the need to create new service flow instance
and simplifies data correlation in some cases.
It was suggested we need a proposal to discuss (see T28)

T27. ALF SCM vocabulary Eclipse WTP "stub" project Mark is going to take
a look at doing this.  We may need to refine the schema and WSDL before
we do that since the current version is not completely valid.

T28.  Define and prototype "callback mechanism"
Tim Buss committed to defining this mechanism for discussion

T29.  Define return values and faults

T30.  POC use case candidates.
We agreed it would be useful to implement one or more POCs based on the
various SCM schemas/WSDLs.  There may be some benefit in trying to do
this before we start any parallel work trying to wrap real products.
T24 seems important to complete before we start codeing in parallel. 
Adam Simantel will suggest a use case for the POC

3. Any Other Business
Liya Jan has provided some feedback on the SCM vocabulary (see
attached).  I have added these comments to the discussion section of the
SCM wikki page.
http://wiki.eclipse.org/index.php/Talk:ALF/SCM_Vocabulary. Please review
and we will discuss it next week.


Attendance has been light and the summer holiday excuse no longer
applies :)

Tim Buss - Serena.       
 


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

--- Begin Message ---

• From: "Tim Buss" <TBuss@xxxxxxxxxx>
• Date: Mon, 9 Oct 2006 17:09:28 -0700
• Thread-index: Acbru3DXImeAiPW5Q76VB8gzuh5ShQAO5tjQ
• Thread-topic: Special ALF SCM Vocabulary Meeting 09Oct2006 - meeting minutes

Special ALF SCM Vocabulary meeting minutes

Attendees:
Tim Buss
Brian Carroll
Mark Phippard
Richard Title
Adam Simatel
 
Agenda
We reviewed the various suggestions as a way to start on this (see
attached email and repeated below as item titles).

Minutes:

1.	CreateWorkspace/ModifyWorkspace/RemoveWorkspace: For
completeness, also need a ShowWorkspaces. Similar comment applies to
many of the other Create* methods. Also, for consistency with the other
API's that take a workspace as input, ModifyWorkspace should take a
"Workspace workspace" argument rather than a "String workspaceName"
argument. 

	This was generally agreed but....

	Generally we prefer the term "list" to "show"

	There should be a way to get a single item (eg: a "get"
operation) since this is the most likely use case in ALF.

	Possibly a list operation would just return a list of ids and a
get would return the more complete "meta data". 

	For lists that are expected to be small, possibly all the meta
data can be returned in the list. 

	A list "filter"  could allow the same operation to return the
single item.

	List operations (and operations in general) will only provide
the data that the caller is authorized to see according to the SCM.  ALF
will provide a authentication credential or token of some sort that the
tool will use to drive its authorization model  (see item 9.)

	There was some discussion as to whether the workspace service or
the SCM server service could list workspaces.  There are two cases.
Listing the workspaces that a workspace service is managing locally to
it.  Listing workspaces know to the server globally.  This requires
further discussion.


2.	AddAssets/RemoveAssets: For completeness, should have a
ListAssets which would list assets (elements) under version control. It
should take a Workspace or Stream as input, and produce a directory
listing of the elements that are under version control in that workspace
or stream. 

     Listing assets could return a very large list.  We would need to
provide an interface that could deal with this an segment the list.  It
is not clear that listing assets in this way is that useful in ALF to we
may prefer to defer this to later.

 

3.	RemoveAssets should probably take a Workspace rather than a
Stream, on the theory that asset-changing operations (e.g.
add/create-new-version/remove) all should be done through a workspace.
The general model should be that you do work in workspaces, and changes
only get into streams by promoting. 

     Remove is required for every create to support compensation. The
more useful case would seem to be against the workspace since it is
generally the model to edit the workspace and then commit the changes.
Some SCMs may have a direct asset remove on the server that would not
require a workspace to use.  This requires further discussion.


4.	IntentToModify ("checkout") should have an inverse operation
("uncheckout"), for the use case where you check out something but then
change your mind. Let's see, should we call it the NeverMind() method? J
Also, I think this is implied, but we should say explicitly that
CreateNewVersions ("checkin") releases the checkout for the specified
elements. 

     This is required to support compensation


5.	CreateStream: For completeness, we should have a ModifyStream
and RemoveStream. 

     Remove Stream is required to support compensation. It is unclear
what Modify stream would do so we will wait to see what is needed to
define it


6.	CreateBaseline: This should take an optional Workspace argument
also. We should allow the caller to specify either (a) Just a workspace
(baseline is current contents of the workspace), (b) Stream (baseline is
latest versions in the given stream, or (c) Configuration (the result of
applying the given Configuration rules). Only one of these 3 should be
specified, or else the baseline is over-specified. 

     The idea is that you could create a baseline from the workspace
config and providing the workspace would be a shorthand for this.  This
seems fine


7.	UpdateWorkset: Should be UpdateWorkspace. Also, should make
clear that "baseline", "stream", and "configuration" arguments are all
optional and the normal case is to update the workspace from its
already-defined configuration, e.g. 

 

      UpdateWorkspace(
        Repository      repository,     // 
        Workspace       workspace,      // 
        Baseline        baseline,       // (optional) if fetching
versions from an existing baseline
        Stream          stream,         // (optional) to fetch latest
versions in the given stream/branch
        Configuration   configuration,  // (optional) overrides
workspace's config-spec to specify what versions to fetch
        Options         options,        // standard options such as
refresh, replace, etc.
        OtherOptions    otherOptions    // tool specific options
      )
 
    This seems fine
 
8.       Need an API to create/modify/remove Components.
	We had previously agree to defer "components" so we will defer
this


9.       Need to (somehow) deal with user-id's, authentication (a
"Login" method), and ownership of assets (pass explicit user-id's, or
get implicitly from logged-in user at time of Create* operation?).

	List operations (and operations in general) will only return the
data that the caller is authorized to see according to the SCM
authorization model.  ALF will provide a authentication credential or
token of some sort that the tool will use to drive its authorization
model.

	There are three mechanisms for communicating an authenticated
"credential" to the SCM service (or any service)
		a. ALF SSO - the preferred mechanism - leverages
WS-Security et al and SAML to deliver a credential to the service in the
SOAP header.
		b. The cookie method.  Services can use cookies whereby
the provide a login and logout operation and all service.  The login
establishes a cookie which the caller must cache and return on each
subsequent call until logout.
		c. The explicit method. An authentication credential (eg
a authenticated session token) is passed explicitly with each service
call.

	a. and b. potentially allow security to be implicit since no
explicit authenticated token is required by the general services.  The
cookie method can provide a good migration path to the SSO method for
this reason.
for method c. it is suggested that we leverage the ALF required, ALF
specific parameter providing an optional element than can  be used to
pass credentials explicitly.  Since all vocabulary operations will take
this argument it provides
a consistent and non intrusive method.

10.  an ALF specific parameter.  This should hold various IDs that
should be returned by the tool on any event that it raises as a result
of the call.  This is used to set the "previousEvent" field in the event
structure and to provide an id for Correlation to facilitate callback.
I don't think there is a suitable ID currently although event ID could
be part of it.  We should to discuss possible formats for this
structure.  It will probably be common to all ALF vocabularies.  The
Base ALF event structure is probably a good place to start.    

This parameter is given to every ALF vocabulary operation.  So far we
have identified the need for it to contain
	a. The current event ID to allow the tool to set
"previousEventID" in any resulting event
	b. A id that identified the Service Flow instance to initialize
and identify a "correlation set" and allow "callback" from the tool to
the same Service Flow instance
	c. An optional security credential/token.

11. Return/response messages 

	Methods that create object should return a least the unique
object ID to allow the object to be addressed.

	Responses should be used for returns/ statuses that might be
expected as part of the usual business logic (eg Build failed) where
there is a usual business intent for handling the case.  In this example
the purpose of build maybe to determine if the source can be built.  If
it cannot different business logic applies.

12 Faults

	Faults should be used for unexpected returns, such as security
access failure, where you would not normally expect to handle the
failure as part of the business logic. Faults are best when the likely
response is to try to use compensation to back out any preceding
changes

	Most things just succeed or fail in an unexpected way so a
commonly defined "status" element may not be that useful in practice.
There may be some cases where it is not clear which type of response
(response vs fault) should be provided but this can only be determined
case by case. 

13.  Datatypes
	A first pass at datatypes has been captured in the SCM schema.
This requires review and appropriate updates

We will continue this discussion in a regular Wednesday meeting this
week.  As always let me know if I failed to capture anything important.

Tim Buss
Serena Inc.

________________________________

From: Tim Buss 
Sent: Monday, October 09, 2006 8:56 AM
To: 'ALF Developer Mailing List'
Cc: 'markp@xxxxxxxxxxxxxxx'; 'rtitle@xxxxxxxxxxx'; 'etm@xxxxxxxxxxxxx';
'Glenn.Everitt@xxxxxxxxxxxxx'; Adam Simantel; Brian Carroll; 'Steve
Taylor'
Subject: Special ALF SCM Vocabulary Meeting Today at 10:00 PDT
+1-303-928-3232 id 6053141#


>From Last weeks meeting minutes
 
T24 Refine and Normalize Operations so they work as a coherent set
Assigned to you.

We agreed to a special meeting set for 10:00am PDT on Oct 9th to focus
on this issue and T29 "return values and faults"

Apologies for the late reminder.

Tim

--- Begin Message ---

• From: "Tim Buss" <TBuss@xxxxxxxxxx>
• Date: Mon, 9 Oct 2006 09:53:09 -0700
• Thread-index: Acbrva21ekLvEAWrQwKQQkZnAeX5fwAAJ+YAAAEnC7AAABJxEA==
• Thread-topic: [alf-dev] rounding out the API in the SCM Vocabulary wiki

oops sorry Richard.  I meant "Thanks Richard"
 
Tim

________________________________

From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Richard Title
Sent: Monday, October 09, 2006 9:50 AM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] rounding out the API in the SCM Vocabulary wiki



Agreed. Except for the first sentence which should say "Richard". :-)

 

________________________________

From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tim Buss
Sent: Monday, October 09, 2006 12:30 PM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] rounding out the API in the SCM Vocabulary wiki

 

Thanks Adam

 

Other things we need are:

 

1. an ALF specific parameter.  This should hold various IDs that should
be returned by the tool on any event that it raises as a result of the
call.  This is used to set the "previousEvent" field in the event
structure and to provide an id for Correlation to facilitate callback.
I don't think there is a suitable ID currently although event ID could
be part of it.  We should to discuss possible formats for this
structure.  It will probably be common to all ALF vocabularies.  The
Base ALF event structure is probably a good place to start.

 

2. return values - really response messages.  Most operations will
provide a synchronous response of some kind even if they later raise an
event.

 

3. faults - we need to define a common format for vocabulary specific
faults and come up with a set of faults for the SCM vocabulary.

 

Tim

 

________________________________

From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Richard Title
Sent: Monday, October 09, 2006 9:12 AM
To: alf-dev@xxxxxxxxxxx
Subject: [alf-dev] rounding out the API in the SCM Vocabulary wiki

First off, apologies for not being that active on the ALF lists lately -
I've been busy getting AccuRev version 4.5 out.

 

I was looking over the API defined in
http://wiki.eclipse.org/index.php/ALF/SCM_Vocabulary (the Java
pseudocode in section 5) from the point of view of whether it is a
complete/consistent/usable SCM API. Generally it seems to be taking
shape nicely. Here are some details-level comments. I can go in and
correct these myself, but I wanted to get consensus from the larger
group first.

 

1.	CreateWorkspace/ModifyWorkspace/RemoveWorkspace: For
completeness, also need a ShowWorkspaces. Similar comment applies to
many of the other Create* methods. Also, for consistency with the other
API's that take a workspace as input, ModifyWorkspace should take a
"Workspace workspace" argument rather than a "String workspaceName"
argument. 

 

2.	AddAssets/RemoveAssets: For completeness, should have a
ListAssets which would list assets (elements) under version control. It
should take a Workspace or Stream as input, and produce a directory
listing of the elements that are under version control in that workspace
or stream. 

 

3.	RemoveAssets should probably take a Workspace rather than a
Stream, on the theory that asset-changing operations (e.g.
add/create-new-version/remove) all should be done through a workspace.
The general model should be that you do work in workspaces, and changes
only get into streams by promoting. 

 

4.	IntentToModify ("checkout") should have an inverse operation
("uncheckout"), for the use case where you check out something but then
change your mind. Let's see, should we call it the NeverMind() method?
:-) Also, I think this is implied, but we should say explicitly that
CreateNewVersions ("checkin") releases the checkout for the specified
elements. 

 

5.	CreateStream: For completeness, we should have a ModifyStream
and RemoveStream. 

 

6.	CreateBaseline: This should take an optional Workspace argument
also. We should allow the caller to specify either (a) Just a workspace
(baseline is current contents of the workspace), (b) Stream (baseline is
latest versions in the given stream, or (c) Configuration (the result of
applying the given Configuration rules). Only one of these 3 should be
specified, or else the baseline is over-specified. 

 

7.	UpdateWorkset: Should be UpdateWorkspace. Also, should make
clear that "baseline", "stream", and "configuration" arguments are all
optional and the normal case is to update the workspace from its
already-defined configuration, e.g. 

 

      UpdateWorkspace(
        Repository      repository,     // 
        Workspace       workspace,      // 
        Baseline        baseline,       // (optional) if fetching
versions from an existing baseline
        Stream          stream,         // (optional) to fetch latest
versions in the given stream/branch
        Configuration   configuration,  // (optional) overrides
workspace's config-spec to specify what versions to fetch
        Options         options,        // standard options such as
refresh, replace, etc.
        OtherOptions    otherOptions    // tool specific options
      )
 
8.       Need an API to create/modify/remove Components.
 
9.       Need to (somehow) deal with user-id's, authentication (a
"Login" method), and ownership of assets (pass explicit user-id's, or
get implicitly from logged-in user at time of Create* operation?).
 
That's it. If people agree generally, I can volunteer to update section
5 of the SCM Vocabulary document in the Wiki.
 
Richard Title
AccuRev
     

********************************************************************** 

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. 

--- End Message ---

--- End Message ---