Skip to main content

[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
> 




Back to the top