Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [alf-dev]ALFSourceCodeMangementVocabularyMeeting+1-303-928-3232id6053141#Wednesday10:00AMPDT - meeting minutes

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

Attendees
Tim buss
Adam Simantel

Agenda
0. Last meeting's minutes (I seem to be missing these but it was a short
meeting and I don't think we discussed anything of significance. Mostly
that I was going to try to update the schema/wsdl/event declaration.)

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

2. Updated Schema and WSDL
I have updated the the SCM schema and WSDL and updated the Wiki pages.
These now depend on the nearly final ALFEventBase_M7.xsd that can be
found in the Architecture section of the Wiki.
  
http://wiki.eclipse.org/index.php/ALF/Vocabularies/SCM_Vocabulary/Schema
http://wiki.eclipse.org/index.php/ALF/Vocabularies/SCM_Vocabulary/WSDL
http://wiki.eclipse.org/index.php/ALF/architecture/ALF_Schemas_M7

I have been able to successfully generate the webservice skeleton using
WTP 1.5.1 all in one (eclipse 3.2).  So mechanically at least we have
some progress.  I added some operations that were missing but I have not
yet gone through and validated the operation arguments with some of the
discussions.  While the operations are thre I am not convinced they are
factored as we would want them.  I am hoping that you can contribute to
that.  I hope to spend some time on event declaration this afternoon and
may have that available for review tomorrow - we shall see.

0. Minutes (not discussed)

1. Status on tasks (not discussed

2. Updates Schema and WSDL

Some points to note.

The schemas published at the links above are preliminary and have
preliminary namespaces names.  In particular the numeric version suffix
(eg M7 and v0.00) will change, probably to a numeric 1 once we finalize
the schema.  The reason for the change is to distinguish non final
versions.  Namespaces, if they are observed, clearly distinguish the
versions.  The intent is that once declared to be the version 1 , a
schema will only change in ways that are at least upwardly compatible
and prefereably interchangeable between versions.  Incompatible versions
will as a general rule use new namespaces although they may reuse types
from the previous namespace.  I am still working out the versioning
issues but just so you are aware of the intent.

I have defined an "EventControl" structure that separates out the values
generally set by the event manager fromt eh rest of the event.  The
intent is that this structure be passed to an ALF complient service for
use inconjunction with raising events and enabling the callback scenario
we have discussed.  The structure is still preliminary and I will
document the intent more fully shortly.

If you are interested in trying out this schema withteh eclipse web
tools project WTP 1.5.1 it is available packaged with eclipse.  The link
explains

http://www.eclipse.org/webtools/

The version I used, 1.5.1 is available here 

http://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.1-200609
230508/

But I notice a 1.5.2 version is already available

http://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.2-200610
261841/

I havn't tried that yet.


Tim Buss (Serena Inc)


-----Original Message-----
From: Tim Buss
Sent: Tuesday, October 24, 2006 9:22 PM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev]
ALFSourceCodeMangementVocabularyMeeting+1-303-928-3232
id6053141#Wednesday10:00AM PDT - meeting minutes

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

Apologies for this being a bit late.  My notes are ratehr terse so this
is the best I can remember.  Please update with anything I missed.
Thanks


Attendees
Tim Buss
Richard Title
Mark Phippard
Eric Minnick
Brian Carroll

Agenda
0. Last meeting's minutes (below)

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

2. Any other business.


0. Last meeting's minutes were accepted

1. Status on tasks

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 

T24 Refine and Normalize Operations so they work as a coherent set
Assigned to you.
We held to a special meeting on Oct 9th to focus on this issue and T29
"return values and faults".  We agreed that we need a straw man WSDL to
review the types.

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.

T25 Reflect Operation refinements in Schema and WSDL Assigned to Tim.
Tim will update WSDL Schema so that it is valid, including Workspace,
events and return codes as seems appropriate.  We will use this a the
basis for further review

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
so we are waiting on Task 24,25,29

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

T29.  Define return values and faults
(see T25)

T31 POC Use case Review - Assigned to Adam and Richard

3. Any other business
We discussed if there was nay faster way to get to the next draft.  The
general consensus was that we needed to have a proposed WSDL, Schema and
event defintion schema to try out and discuss.  Tim said he would try to
work on that. 

Tim Buss - Serena.        
  

-----Original Message-----
From: Tim Buss
Sent: Wednesday, October 11, 2006 4:02 PM
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 11th at 10:00AM PDT 

Attendees
Tim Buss
Richard Title
Brian Carroll
Adam Simantel

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

0. Last meeting's minutes and special meeting minutes were accepted

1. Status on Tasks - we skipped this item but....
Richard committed to updating the SCM use cases based on our discussions
Adam will take a look at determining the top datatypes to define.
Tim will define the ALF "structure" we need to pass to each operation.

2. Continue the discussion around T24 "Refine and Normalize Operations
so they work as a coherent set"

We discussed the "use case' feedback submitted by Liya Jan

Use Cases
a)Create a workspace
 - CreateWorkspace method must have a user and password parameters, or
should always come after some kind of login method

We agree
 
b)Modify a workspace
I think this use case is irrelevant - if you change load-rules,
configuration, or location of the workspace, it is a different
workspace, so you should use 'CreateWorkspace' method for it; unless you
mean the "Switch" operation - create a different workspace under the
same location - in this case location parameter is irrelevant.

There are two models for this.  i) The SCM service has a notion of
workspace config.  ii) workspace is only a "client side" notion.  For
the first it seems to make sense to have some defined way to modify the
server side workspace object.  For the second case it may make less
sense depending on the client implementation.  We are not sure of this
and feel that we need to get closer to real implementation models to
decide for sure.  Possibly it is optional or extended functionality

c)Create new versions of an element
 - additional parameters for CreateNewVersions method:
        String   comment,       // optional comment
        String   issueId        // optional issue id from supported
Issue Tracker

We agree that "Comment" should be there
We agree that associating "issueId" with a version is a common use case
but not all SCM tools allow the association. We discussed the
possibility of a set of general attributes but that has the same issue.
Possibly this is optional or extended functionality.  For ALF, the
association of issue and element version could be held by some other
tool which would satisfy the use case.
 
d) Create a new stream (branch) to support parallel development
 - additional parameter for CreateStream method (i think it should be
CreateBranch):
  otherOptions OtherOptions // tool specific options

We agree
 
e) Capture a baseline (snapshot) -> i think CreateBaseline should be
CreateTag

Assume CreateTag means CreateLable we disagree.  CreateBaseline could be
implemented using a Lable but Labels can be used for a number of
purposes and CreateBaseline is specific function
 
f) Promote versions up to a higher-level stream or branch -> I think
this use case is a private case of 'Perform merges of versions, from one
branch/stream to another' 

This seems like a reasonable point. Possibly we could combine the
operations in the API

We discussed Datatypes
a) fileSelection - It was proposed that we define a common
definition/format for this. However, it seems likely that this may need
to be tool specific.  Thus we will only know once we have some real
examples

b) General approach - use the POC proposal to determine what we need to
define first

POC proposal
a)  We revisited this again and decided to expand it slightly to add the
need to check in artifacts generated by the build.  It was felt that the
poc as it stood while a common use case was maybe too simple to bring
out the issues.

Tim Buss - Serena.        
 
-----Original Message-----
From: Tim Buss
Sent: Monday, October 09, 2006 5:09 PM
To: 'ALF Developer Mailing List'
Subject: RE: 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.

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


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

_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev


Back to the top