[alf-dev] Re: Comments on the Flash Demo

["Tim Buss" <tbuss@xxxxxxxxxx>]

Hi Mike,
Thanks for you kind words about the demo.  I am repeating Brian reply to
your questions here since it evaded the newsgroup and I have added some
additonal notes. Please pardon the repetition.

1. We had originally looked at using publish-subscribe model in general and
WS-Notification in particular, but on further investigation found both to be
inappropriate. One notion behind the ALF Service Flows is that of "managing
the process". That is, having a development manager determine what the
appropriate response to an event should be, rather than leaving it up to
processes to determine which events to respond to.
WS-Notification turned out to not be a good fit for certain classes of
tools, for example batch-oriented tools. There were several issues with
WS-Notification, especially if used on the "front end" of the Event Manager
to subscribe to Events emitted by tools. The problem was that with certain
classes of tools, such as transient, batch-oriented tools, it was difficult
for the EventManager to discover that the tool was running and then
subscribe to it to be notified of the event.

[Tim - Other arguments against WS-Notification are that it made it more
onerous than necessary for a tool to participate in ALF and it make security
a bit more challenging. We therefore elected to specifiy a simple ALF
defined web service for tools to call to raise events.  In the future we may
add support for WS-Notification to ALF as a alternative mecahnism if that
spec gains more acceptence.]

2. The meta model for ALF Events is described in the ALF Architecture
document. A link to it can be found on the Architecture portion of the ALF
home page at www.eclipse.org/alf.

[Tim - I suspect the exact schema for the ALF event message may be refined
as we move towards the 1.0 release.  What is less defined as yet is how this
extends to services that tools that participate in ALF might implement.
Broadly, to participate in ALF, a tool only need provide (or have provided)
SOAP web services.  An ALF enabled tool only needs to provide Web services
that meet certain standards and conventions and provide suitable ALF events.
An ALF complient tool would implement specific ALF vocabulary based messages
in addition to providing ALF events and may provide particular functionality
around these messages.  We are just starting to define the framework for
this.  The initial ALF POC really only addresses "participation" and
"enablement" and so does not emphasize the "vocabulary" aspect.]

3. We had some meetings with the Higgins team. Their direction on Identity
is promising but the delivery schedule did not match up with ALF's. In
addition, Higgins only addresses an aspect of what is needed for ALF SSO.
ALF needs to deliver its 1.0 release candidate before the Higgins release
will be available. I have been following developments with Higgins and
reevaluate its applicability as we are planning the post 1.0 efforts. We
have has a focus on pluggability and extensions in the SSO design effort, so
incorporating component from Higgins, such as and Identity Server, should be
quite doable.

4. I'll leave this for Tim Buss to elaborate on, but, in general, the BPEL
engine is intended to be pluggable, where any BPEL engine that conforms to
the BPEL spec should be usable.

[Tim - It is the intent of ALF to treat BPEL as a standard and to regard
BPEL engines as interchangeable.  We considered trying to use the TPTP
engine in the ALF POC but found that it did not meet our needs at that time.
We also considered a number of other open source BPEL efforts.  ActiveBPEL
was the only complete OpenSource implementation available.   The main issues
with TPTP, if I remember correctly, were that it did not fully implement the
BPEL 1.0 spec (error and compensation handling in particular) and would have
taken some considerable work to run it as a standalone engine.  We plan
re-evelauate it periodically and hope to use it as an example implementation
in the future.

5. Yes, the project team recognizes the issues with examples that include
commercial software that requires licenses, and has two approaches. First,
all the contributors have agreed to provide a "web services" stub that would
allow the ALF POC example to be run without any proprietary software being
needed. When we post the POC as a downloadable demo to ALF CVS, it will
contain those stubs. Secondly, the team has already started to incorporate
open source tools into the example. [Tim can elaborate on this work.]

[Tim - not sure I have much to add right now.  We plan to expand the POC in
the short term to include some open source products, CVS and Bugzilla are
under consideration.]

Brian [and Tim]

"Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx> wrote in message
news:dtnja8$m4i$1@xxxxxxxxxxxxxxxxx...
> I watched the ALF Flash demo
> (http://www.eclipse.org/alf/ALF%20POC%20Demo.htm). Great stuff! Very
> compelling. I really enjoyed it, and have already pointed several people
to
> it to learn more about the project.
>
>
> I have a couple of questions and comments.
>
>   1.. For some reason, I had been assuming that the integration engine was
> going to be based on a publish/subscribe model. But it doesn't appear
that's
> the case. Can you point me to the right document I can read to understand
> how the action side of service flows are defined?
>
>   2.. I am not sure I understand the meta-model for the data being passed
> when events fire. I would assume that this is the "secret sauce" for tool
> integration in ALF, but it's not really mentioned in the demo. Is this
> because it's still undefined?
>
>   3.. With regards to the single sign-on, have you made a determination as
> to whether Higgins will meet your needs?
>
>   4.. Just out of idle curiousity, has the project evaluated the BPEL
engine
> that in the progress of migrating from TPTP to STP? The GPL license used
by
> ActiveBPEL could definitely be an issue. (I really mean "could". I am not
> sure how the linking works in this case, so don't know what the GPL
license
> semantics would be like in this scenario. But as a general statement, we
> attempt to avoid GPL code in Eclipse projects.)
>
>   5.. A word of caution on samples and examples, just in case. As an open
> source community, we need to ship samples and examples that leverage open
> source runtimes. So at some point, you're going to have to think through
an
> example that leverages open source code, rather than proprietary ones. I
> apologize if I'm stating the obvious or repeating what Bjorn has already
> said, but I don't want to make the mistake of not being explicit on the
> topic.
>
>