[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] Event Map schema
|
Vinay,
I'm not sure I understand your question but here is some discussion that
may illuminate.
Assuming the SCM and Build tool share the workspace then presumably, the
ALF Service flow that performs this operation first calls the SCM to do
the Workspace update and then calls the Build tool to build the
Workspace. So a couple of questions are:
1. What event triggers this service flow to run
2. Is the "get" operation synchronous with service flow or will it
complete asynchronously and raise an event.
On 1. I suppose this could be initiated directly by a user or it could
be the result of a change in the SCM (eg a checkin). In either case,
some information will be sent with the event. This information must be
sufficient enough that the ALF service Flow can query the originating
tool for additional data if it needs to. The originating tool may be
implied in the case of a direct user request. In the case of a "checkin"
we would presumably know the file id but we may need to find the branch
or configuration and correlate that with a build configuration. Exactly
how that is done may depend on the tools being used.
On 2. either case may work. The synchronous case is easier to program
since there is no disjoint in the logic. If the "gets" are, predictably,
of short duration then this is a reasonable approach. If, however, the
"gets" for the projects you build are of long or unpredictable duration
then the an asynchronous approach is preferred. The asychronous approach
would require a second service flow to handle the "workspace update
complete" event and maybe a third service flow to handle the "build
complete" event if we want it be thorough. A difficulty is how to
correlate across these service flows. There are two approaches proposed.
The first approach relies on a very high level of ALF conformance. In
this approach the request and response messages for the service provided
by ALF conformant tools all conform to an ALF defined message schema.
There is an obligation for data that is passed into a service to be
returned to ALF via any event that results from invoking that service.
This is all well and good but it is unlikely that we can rely on there
being this level of conformance certainly in the short term.
The second approach relies on ALF being able to correlate tool specific
IDs and maintain that correlation across service flows. A correlation
store as a common service has been proposed to do this. Thus when we
request the SCM to update the workspace we identify it with an SCM
workspace ID and when the SCM completes its work it will rasie the event
and pass the Id of the workspace it updated. The subsequent service flow
that runs on the event can use this id to look up any information store
in the correllation store associated with that ID.
Tim
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Nath Penmatsa, Vinay
Sent: Wednesday, June 14, 2006 9:16 PM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] Event Map schema
(sorry if you see this mail twice ... Seems like it got lost the first
time)
A little confusing to me is how even the 3a would work. Once a check-in
is done, I would like to have an incremental build done. Now assuming
that as discussed in "workspace discussion" thread there is a shared
storage area, unless ALF completes issuing a get and fetch this location
from SCM server service, the build tool service invocation as part of
the service flow cannot happen (or probably won't be useful) If there is
something that ALF needs to pass to the tool/build service, is the
"EventDetails" part of the issued event used? If so, there should be
some transformation involved.
How is this entire procedure different from the SCM tool including this
information as part of the Event (or EventDetails if it is more
appropriate) when it issues the event in the first place? This
particular case is when, for e.g, I need a build, on a central storage
where I run builds after every check-in.
-Vinay
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tim Buss
Sent: Tuesday, 13 June 2006 10:24 PM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] Event Map schema
Either scenario could be implemented but the 3a variation is much
simpler, makes less assumptions of the build tool and would be the
approach I would take in general. There would need to be a very
compelling reason to have the Build raise an event with the intent of
getting additional information back to itself. Do you have a use case
for this?
We have proposed a synchronous ALF "event" that would return data to the
caller. The primary intent of this proposal is to allow status to be
returned to a human user. Such a mechanism could be used in the
scenario you propose since it would allow the tool to code to ALF events
but make the request for information more direct. Since it would
require a specialized Service Flow to service the synchronous event, 3a
would still be my preference without some compelling reason to split the
flows up.
The
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Nath Penmatsa, Vinay
Sent: Monday, June 12, 2006 10:05 PM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] Event Map schema
By "discovery", I meant an event that invokes something similar to the
"getObjectInfo" service that you mentioned
May be a simplified example would help.
A scenario-
1. A file is checked in to CVS
2. CVS sends a message to ALF with a build event, including the object
id for the file
3. ALF messages to Build Service as part of the service flow (assume
only one service is defined)
Now, the build service would require more information regarding the
object, probably the workspace detail.
4. Build Service sends an event to ALF which calls the "getObjectInfo"
service.
5. The build service executes the build with this object info.
A variation to the above -
3a. ALF just executes the service flow that defines three services.
- A getObjectInfo service
- A service exposed by the build system to which this object
info is passed
- A service exposed by the build system which does the
appropriate build
The difference is that in the former case the "getObjectInfo" service is
called as required And in the latter, the service is defined statically
as part of service flow.
Which one is expected/better?
If the first is correct, does ALF make "getObjectInfo" a preferred
service, since this might be an oft-used service in the flows and would
benefit from a vocabulary.
Thanks for the detailed mail which also explained other obscure things.
-Vinay
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tim Buss
Sent: Tuesday, 13 June 2006 4:02 AM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] Event Map schema
The assumption is that the ALF service flow is used to call the
"getObjectInfo" services and that the service flow takes action as
appropriate. If another tool needs the data then the service flow will
pass it via some service that tool exposes.
There are some special cases we are considering where the data may be
large. ALF may provide a service to allow such data to be passed by
reference assuming the originating tool cannot do that in a generic way
(eg shared file system, webdav, ftp). ALF vocabularies may define
common schema allowing such data to be interpreted.
I'm not clear what you mean by "discovery" event. Perhaps you could
elaborate? Here is an explanation of the current intent.
Tools can provide whatever services they want, provided the services are
exposed as SOAP based web services and are calleable from BPEL. These
services will be advertised as WSDL services for use by the BPEL servce
flow or other web service clients. ALF vocabularies mya define a set of
prefered services and service structures for particualr classed of
tools. But thes would be advertised via WSDL in the same way.
There is no general requirements for dynamic discovery of services since
it is really necessary to know the service definition at design time.
An endpoint fix up may be needed at deployment time or when the system
configuration is changed. Using a service bus as a deployment vehicle
may be a way that can be addressed although if XML is the deployed it
may not be that difficult to arrange a static fix up. ALF does not
specify or recommend on this aspect at this time since it will depend
very much on the deployment environment and we would like to remain
platform agnostic in those details. In time ALF may document some
example platform configurations and best practises for using ALF in that
environment.
Not sure if this is relavent to you question but the event can provide a
"callback" url which can be used to dynamically identify the source of
the event but you would need to know the service to call since you have
to write the service flow in advance. The intent of this was to allow
multiple instance to of the same tool but it needs some further
refinement.
tim
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Vinay
Sent: Monday, June 12, 2006 2:06 PM
To: ALF Developer Mailing List
Subject: Re: [alf-dev] Event Map schema
Hi Tim,
Does it mean that the tool which created this event should also define
additional non-core service to provide more information about the
"object" to other tools involved in the service flow if required?
If so, then we need a "discovery" event invoked on ALF or probably
bypass ALF and use ObjectType to discover this information. Right?
-Vinay
Tim Buss wrote:
> Yes they are tool specific. The idea is that I should able to call a
> web service provided by the tool to query for more information about
> the object or objects that were identified in the event. I should be
> able to do this at any time after the event has occurred, so the
> Object IDs the tool provides should be durable. The Object Type might
> be used to determine which service to call but may be mostly
informational.
>
> Tim
>
> -----Original Message-----
> From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Vinay
> Sent: Monday, June 12, 2006 11:09 AM
> To: ALF Developer Mailing List
> Subject: Re: [alf-dev] Event Map schema
>
> Are the contents of Object and ObjectType left to the tools that
> integrate to ALF?
> So, if I check-in a source file A.java, the objectType can be sth like
> "JAVA_SOURCE" and object can be "A_java_v_1.9" (assuming version 1.9
> of A.java is created)?
>
> -Vinay
>
> Tim Buss wrote:
>> Product is intended to be a unique string in the context of ALF,
>> naming the product that is emitting the event. Version is a string
>> describing the version of that product.
>>
>> Object is intended to be a unique string in the context of Product,
>> identifying the entity inside the Product that is emitting the event
>> -
>
>> an instance id. ObjectType is a string that describes that entity -
>> a
>
>> class id. There is an array of Objects since there may be a number
>> of
>
>> objects associated with the event.
>>
>>
>> Tim
>>
>> -----Original Message-----
>> From: alf-dev-bounces@xxxxxxxxxxx
>> [mailto:alf-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Vinay
>> Sent: Monday, June 12, 2006 10:32 AM
>> To: alf-dev@xxxxxxxxxxx
>> Subject: [alf-dev] Event Map schema
>>
>> Hi,
>> The ALFEventManager seems to be expecting an <Object> node which
>> is not defined by EventActionMap.xsd (as given in
>> EventActionMapSchemaParser) Should the schema be modified?
>>
>> And, is there an explanation somewhere of the following elements -
>> - Object
>> - ObjectType
>> - Product
>> - ProductVersion
>>
>> The rest are understandable.
>>
>> Thanks,
>> Vinay
>> _______________________________________________
>> 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.
>> _______________________________________________
>> 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
>
_______________________________________________
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
_______________________________________________
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
