FAQ (Frequently Asked Questions)

Business Questions

Why does the computing industry need ALF?

ALF is intended to address the needs of managers of development projects today.  Development tooling covers most aspects of software development, yet the development domain is so broad that no one vendor can “do it all”.  So, the development process inevitably involves handoffs among many tools to accomplish a project from conception through deployment. Yet the tools involved are not coordinated, in the sense of sharing or synchronizing data or supporting a common process.  ALF is intended to provide the glue that makes the coordination of tools possible.  No single vendor could afford to create a sufficiently rich and open infrastructure by itself – and even if they did, its proprietary tinges would inhibit universal adoption.  Instead, ALF as an open consortium under Eclipse oversight is coordinating to produce a “glue infrastructure” that all software development managers need to coordinate the variety of tools their developers use.

Who is developing ALF?

ALF involves both tool vendors and the consumers of those tools.  The expectation is that tool vendors will contribute the bulk of the code for the framework which will then be shared amongst those vendors. Of course, consumer companies are welcome to contribute too. Consumer partners will be especially valuable participating in the requirements definition and in providing oversight to designs and testing the solution as it is developed.

How does my company participate in ALF?

Join Eclipse at www.eclipse.org and sign up to participate in the ALF project.

How can we rely on open source code to build mission and life critical applications?

ALF is intended to support the development and maintenance of applications, not be a component of such a critical system.  So even though the peer-review process of open source development is likely to result in high quality code, such quality does not necessarily confer quality on the application being developed, critical or not.

The quality of the application built using ALF depends on the quality of the process, tools, and people used to build it.  Those processes and tools will plug-in and leverage ALF, but will not depend on ALF for quality.  If anything, having a tool integration framework, such as ALF, is likely to reduce errors in cross-tool and cross-person handoffs, and so may result in improved quality, much as coordinating process across the entire suite of tools and developers is also likely to help.

Technical Questions

ALF talks a lot about “vocabularies”. What is a “vocabulary”?

ALF is based on using web-services for communications among tools and the framework.  An extensible set of web service messages will be defined to support that communication.  A strong data administrative approach is being followed to provide a balance between tool interchange and interoperability while allowing proprietary extensions.  A part of that approach is defining the messages exchanged in the framework.  The “schema”, or data model, for those messages is referred to as the vocabulary. The vocabulary defines data elements, the overall message structure, and events.

What will prevent the first vendors who participate from controlling the definition of the vocabularies and thereby give them an advantage?

There will be several levels of architectural oversight: First, the ALF subject area vocabulary subcommittee will be populated by a mix of both vendors and users before it will be chartered.  Second, the ALF Vocabulary Architecture Board will provide the oversight to coordinate the work done in the various vocabulary subcommittees, looking to avoid redundancy, undue proprietary influence, and to factor out common portions of the models. Finally, the Eclipse project management provides a final review and check on the vocabularies before they are published under the Eclipse name.

My company is a software tools vendor. How does my company enable its tools to work with ALF?

ALF provides the overall framework and oversight, but does not dictate the data model for all subject areas.  The expectation is that a consortium of vendors will agree on a core models for each subject area.  You should join ALF and participate in the definition of those models, and then wrap your tools with a web service layer to plug your tool into the ALF framework.

My company has built custom development tools.  How do we integrate those with ALF?

Same as above.  If your tools correspond to a subject area for which a vocabulary has been defined, map your tools’ data models to that and implement a web service wrapper around your tools so they can plug in to ALF.

Eclipse is a client-side IDE and most of the Eclipse Framework is oriented around a desktop client.  How does the Eclipse IDE work with ALF?

The Eclipse IDE is the primary client for ALF.  In addition, a web client will also be provided.

Don’t vendors’ development tools already provide a user interface?  Will users be constantly switching between a tool’s native user interface and ALF?

Many developers, who have gained expertise from daily use of a particular tool’s user interface, will continue just as they have been doing, and will not need to use the ALF user interfaces.  ALF is about filling the “gap” between tools, not replacing a tool or user interface.  In fact, the major impact on most developers is that they will need to do less work, especially when they change from one tool to another, since ALF will have synchronized the data among the tools.  Development managers will largely be using the ALF user interface to monitor the progress of the project.  Also, new developers, who may not already be experts in using a particular development tool, may find they prefer interacting with the abstracted ALF user interface.

How does ALF differ from CDIF?

The Common Data Interchange Format (CDIF) initiative was developed to allow the interchange of data models among CASE tools in the 1990’s.  However, CDIF exchanged entire models of the latest snapshot, leaving the receiving tool to perform a differencing operation to determine what had changed.  The ALF vocabularies will be designed to convey what has changed, thereby minimizing the work required of the receiving tool.

Is there a notion of compatibility with ALF?

ALF is extensible with 3 levels of interoperability defined: ALF Core, ALF Extended, and Proprietary.  ALF Core is a minimalist vocabulary which all tools are expected to support – a “lowest common denominator”.  The ALF Extended extends the core with useful, but perhaps not universally supported elements.  Finally, any tool can communicate its unique or proprietary data as extensions to the ALF Extended vocabulary.

Why is ALF based on open standards, when proprietary communications formats are likely to perform much faster?

ALF is a consortium of vendors (each with financial constraints and objectives) and companies that use the vendor’s tools (each expecting increased interoperability and development efficiency from ALF).  The selection of open standards, such as web services, allows ALF to be built with minimal upfront investment and design, leveraging open and standard technologies to the greatest extent.  In addition, the vocabulary design focuses on large-grained interactions, not on “chatty” fine-grained coordination among tools, so while performance is a consideration, it is secondary to interoperability as n objective

Data Models (vocabularies) may need to evolve over time. How will that be addressed?

One of the the significant holes in SOA and web services to day is versioning and dealing with change.  Where there are a number of techniques that can be usedto solve pieces of the problem, there is not even consensus on how a version of an XML Schema or WSDL document should be identified (via namespaces, elements, or attributes).  Ideally, ALF would build upon a versioning foundation provided by the W3C, OASIS or other respected standards body, but the current reality is that approaches are various and contested.  Subject to approval by the ALF committee, we expect to adopt a combination of techniques (largely based on abstraction and dynamic, late-bound extensibility) to address both extensibility and versioning.

The ALF project packages an extensible and exemplary engine to execute these rules.