[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] Help on Startup
|
Hi Igor,
Very cool! We are please to learn of your
interest.
Tim Buss will likely respond also, as he worked on the
BPEL aspects and should be able to provide more detail. ALF is intended to
be a tool integration framework. It is a fairly general
integration framework that is tied to the ALM tool space by the
vocabulalries (WSDLs defining services and events for various areas of ALM, such
as SCM, BUILD, etc.) The approach we took was to "fill in the gaps" and
write only those aspects we could not obtain from other Eclipse or open source
projects. For example, one of the gaps was the Event Manager that I'm
pleased to hear you have tried. Two components we did not build
were a BPEL designer tool and BPEL engine, since there were open source
projects such as Apache ODE as well as some promising work at Eclipse on BPEL
designers and engines.
So the ALF architecture has two "pluggable" components:
the BPEL designer and BPEL engine. The specifics of how you deploy a
BPEL service flow into the BPEL engine is specific to that engine. We had
used Active Endpoints, JBOSS jBPM, but have not spent much time with Apache
ODE.
The notion of the event-driven approach was that tools
would emit ALF Events when some significant change occured (e.g. a build
completed or a configuration was approved for rollout to production, etc.)
The ALF Event structure defines a basic set of fields that are useful
for:
1. filtering and routing the event (such as the
type of entity and tool involved and the general nature of the
event)
2. tracking and logging the effects of the
change in the tool that raised the event, as the effects propagated through all
the programs called as a result of the BPEL process.
Beyond that Basic Event information, you have almost
complete freedom to add additional data to the Basic Event structure. We
envisioned two general types of event definitions:
1. One was a lightweight event (essentially the
notion of a "signal") that was small and conveyed just enough information to
identify the event and its general nature. The ALF Basic Event structure
contains sufficient information for this purpose. The thinking was that
(assuming the program that raised the event was long running), when the BPEL
process started, it had sufficient information from the Basic Event to make a
call back to the tool to obtain details on the entity that was
changed.
2. The other type of event was one that conveyed
all the information needed for BPEL processing with it. This generally
required extending the structure of the Event beyond the Basic Event, usually by
adding the data about the entity that was changed that triggered the raising of
the event. This approach is also appropriate for short-lived processes,
such as a BUILD, which may have completed and terminated by the time a BPEL
process needed to call back to get details about the change.
In general, the Event Manager largely performs its
inspection, routing and filtering and then passes the original event essentially
unchanged to the BPEL process (assuming it was not filtered out). So the
information available to the BPEL process consists of the Basic Event structure
plus and entensions you have defined to convey more details about the
event. The Event Manager may make a few changes to the elements in the
SOAP Header (Addressing and Security), but in general the event structure is
passed through unchanged.
In addition to determining how to deploy a BPEL
definition from your chosen BPEL designer to your chosen BPEL engine, you will
want to create an "Event-Action" map. There is a small Eclipse UI
plugin for creating and deploying those maps to the Event Manager. That
mapping specifies the values of certain key fields of the Basic Event that the
Event Manager can use to filter and route the Event to the appropriate BPEL
engine instance to launch the BPEL process appropriate for that
event.
If I understand your scenario, it seems you want to
gather statistics from your development tools for reporting by BIRT. Is that
correct? While ALF was intended more to synchronize data among a set of
tools, your scenario is a good fit for ALF, and should work well. The only
thing to keep in mind is that web services in general are heavyweight, and you
generally want them to be large grained and not overly frequent (simply due to
the overhead of packaging, transmitting, and parsing the XML message. So
for reporting purposes it might be appropriate for each tool to batch up a
number of items to be reported into one event, rather than thinking of ALF
Events and processing as lightweight and inexpensive.
Hope this helps. Let us know if we can
help.
Regards,
Brian
Brian
Carroll | Eclipse ALF Project Lead | Serena Fellow
(O)
(503) 617-2436 (C) (503) 318-2017
Hi
guys!
This is my first mail to the user's group!
I strong believe on ALM solutions and the velocity of the eclipse
community.
We're starting the development of an ALM solution using ALF.
Our goal is to "package" an environment with some useful free projects
orchestrated with ALF and using Eclipse BIRT reports...
We have chosen Apache Ode as BPEL provider...
I have downloaded and installed ALF M7 and tested ALFEventEmitter
successful...
I have setup ApacheOde and created and simple BPEL flow...
What are the steps to:
- Create an ALF ServiceFlow to delegate to my BPEL
Engine (Is just deploy an ALF flow using the Eclipse Plugin pointing to my
BPEL flow ???)
How can I resolve WSDL differences ? Can I raise an ALF Event using a
complete different WSDL for example ?
Sorry for my questions... I have read the architecture documents and
understand the concepts, but now I want to setup the environment...
It would be great if someone have another document for start up or
examples!
Thanks a lot!
Greetings from Brazil!
**********************************************************************
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.
**********************************************************************
