[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[alf-dev] Re: need more details
|
Hi, Charles,
The ALF project has selected Service Oriented Architecture (i.e. web
services + Events + Best Practices), so to be accurate, instead of an "API",
you should think in terms of a web service interface (for example a contract
expressed using WSDL).
To answer you first question, we need to two answers: a short term answer
and a longer term answer:
1. In the short term, the intention of the ALF project is to provide the
plumbing and process orchestration to allow the integration of tools, and
you will be able to integrate tools without ALF having defined a common set
of commands. ALF will provide data mapping, so that web service operations
provided by tools can be invoked.
2. In the longer term, we first have to recognize that Eclipse is not a
standards organization - instead it is focused on developing useful working
code. So while longer term, the contributors and comitters of ALF will start
to define XML vocabularies for a variety of subject areas (for example: user
interface definition, business process definition, physical database
representations, ...), those XML vocabularies will be examples, not
standards.
The motivation for the short and long term strategy is to make the output of
the ALF project useful quickly and then improve over time. Having
participated in a number of consortium modeling projects involving vendors,
I know first hand that it can take a long time to achive agreement on data
models. We did not want to delay the benefits of ALF by making the
definition of XML vocabularies a requirement up front. Instead, the intent
is to make ALF useful in very early releases (though the individual
companies that adopt it will have to do additional work to "wire together"
the operations of different tools they are using). Over time, as the XML
vocabularies are defined, the use of ALF should become much more productive.
For example, each vendor providing an interface (or an ALF mapping)
conforming to the XML vocabularies published throug the ALF project. (And
keep in mind that "conforming" is perhaps too strong a word, since the ALF
XML Vocabularies will be well thought through examples - not standards.)
To answer your second question regarding process: ALF intends to provide
the mechanisms for integration and interoperability among tools. Two of the
capabilities ALF will provide are a process designer and a BPEl-based
process engine. The ALF infrastructure will be pluggable, so you could plug
in a different BPEL engine. However, ALF will not define a process, such as
RUP. If you wanted, you could build ALF service flows that would support
RUP, or any other methodology of your choosing. If enough of the community
is interested, it might make sense to form a follow-on project to build
examples of service flows that support one or more methodologies. but that
is not a focus of ALF. So think of ALF as an enabler for what your are
asking for, not the provider of it.
Regards,
Brian Carroll
<charles.w.lambert@xxxxxxxxx> wrote in message
news:dch1f3$5aa$1@xxxxxxxxxxxxxxxx...
> Is this project like a specification of commands for different types of
> tools? For Example an API for version control such as 'check out', 'check
> in', 'branch'.
>
> Or is it going to define a software development process like the Unified
> Process along with API's for tools to plug in at that point in the
> process?
>
>
> Charles Lambert
>