[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [alf-dev] Event Map schema
|
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
On 6/13/06, Tim Buss <TBuss@xxxxxxxxxx> wrote:
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
