Application Lifecycle Framework

This project has been archived.

This Eclipse project proposal (refer to the Eclipse Development Process Document) is posted to declare the intent and scope of a Technology PMC Project called the Application Lifecycle Framework project (ALF). In addition, this proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and join the project. Please send all feedback to http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.almiif.

Background

An Application Lifecycle is the continuum of activities required to support an enterprise application from its initial inception through its deployment and system optimization.  

The Application Lifecycle Management (ALM) integrates and governs the planning, definition, design, development, testing, deployment, and management phases throughout the application lifecycle.  Currently, the application lifecycle is supported by numerous heterogeneous, multi-vendor applications which are integrated in a point-to-point manner.  Point-to-point integrations are adequate only for small numbers of integration endpoints and typically create more complexity in developing and managing tools than they solve.  Given the myriad of products, tools, and services that are typically integrated to manage an application change from its inception to fulfillment, the number of point-to-point integrations drastically increases and administration and maintenance become complicated for both customers and vendors alike, with the risk of error increasing significantly.  For example, consider the following set of tools that are typically integrated across ALM solutions: 

  • Requirements Management (e.g., Borland CaliberRM, Serena RTM, Telelogic DOORS, etc.)

  • Change & Configuration Management (e.g., Rational ClearCase, Serena ChangeMan, etc.)

  • Version Control (e.g., CVS, etc.)

  • Application Modeling (e.g., Borland Together, Rational Rose, , etc.)

  • Software Development (e.g., Eclipse IDE, IBM WebSphere Studio, Microsoft Visual Studio, etc.)

  • Defect Tracking (e.g., Bugzilla, Mantis, Serena TeamTrack, etc.)

  • Quality Assurance (Mercury TestDirector, Segue SilkCentral, etc.)

  • Deployment (e.g., IBM Tivoli, Macrovision InstallShield, etc.)

  • Application Security (e.g., CA Netegrity, Entrust, Secure CodeAssure, etc.)

  • Project Portfolio Management (e.g., Niku Clarity, etc.)

The number of possible combinations of a set of n integration points taken 2 at a time is given by (n!)/(2!(n - 2)!). This short list includes 22 products. Even if you take a smaller subset of a typical cross-product integrations within ALM involving say 10 products, a point-to-point integration of these 10 products would involve 45 unique integrations, e.g., Telelogic DOORS <-> Rational Rose, Telelogic DOORS <-> Mercury TestDirector, Serena ChangeMan <-> Rational Rose, Serena ChangeMan <-> Mercury TestDirector, etc. This does not scale.

Motivation for the Eclipse Project

To effectively manage the application change across the lifecycle, these various product silos and tools need to be integrated.  This introduces a complex technical challenge for both vendors and customers alike as the point-to-point integration becomes cost prohibitive to develop and maintain.  Vendors know that the creation of any interoperability framework is an enormous undertaking for any one vendor.  In addition, this complex and difficult work does not provide a competitive advantage for the vendor's commercial solutions.  Furthermore, if developed as a proprietary component, this framework will not guarantee the necessary level of interoperability and will push the customers into a single vendor suite of solutions which is neither technologically practical nor financially feasible in most cases.

Solution

Goal

The goal of the ALF project is to solve this integration problem by introducing a central negotiator that manages interactions between applications.  This service-oriented event manager provides a very useful uncoupling function.  Using an intermediate communication format prevents having to integrate an application several times with several other applications, and simply carries out one integration on the central node.  The central node then carries out communication with other ALM applications through orchestration of their corresponding web services. 

The ALF Solution consists of three main parts, namely, ALF Events, Provider Services, and ALF Service Flows.

1.  ALF Events and Event Vocabulary

The ALF project will create an event (i.e., signal) vocabulary for initiating the conversations between tools. The event vocabulary will cover common concepts (requirement added, new defect created, relationship created, etc.). The project deliverable for the event vocabulary is a common set of WSDL definitions and the associated specifications/documentation. 

ALF Committers, organized into subject-matter sub-groups, will extend the event vocabularies. To provide a framework that leads to a homogenous and consistent overall model, ALF will specify the overall style, organization, and constraints.

An Event is a web service message sent from the tool to the ALF infrastructure.  Within ALF, an Event Manager determines which ALF Service Flows should be invoked.  Event handling is based upon a publish/subscribe model between Events and Service Flows. The Event Manager dispatches the appropriate ALF Service Flow to start a service flow instance.  Tools from multiple vendors should emit the same event type thus making the operation of ALF independent of the particular tool.

The ALF committers will specify the set of standard Events.  Software developers may extend these events using ALF Designer, an Eclipse-based tool.

2.  Provider Services and Service Vocabulary

For a tool to participate in the ALF framework, it needs to expose critical large-grained set of web services (WSDL contracts) to query and return information or take actions.

The ALF project will create a common service standard for the conversations between tools to provide a framework that leads to a homogenous and consistent overall model.  ALF will specify the overall style, organization, and constraints.

ALF Committers, organized into subject-matter sub-groups, will create the service vocabularies. The service vocabulary will cover common entities (requirement, defect, etc.).  Software developers may extend these services using ALF Designer, an Eclipse-based tool.

3.  ALF Service Flows 

Web Services registered with the ALF framework can be orchestrated to query information (e.g., get data, status, etc.) and/or take action (e.g., save data, change data, etc.) according to the ALF Service Flows defined at design-time. ALF Service Flow definitions will be written in OASIS Web Services Business Process Execution Language (BPEL).  The ALF project will provide an example implementation using an existing BPEL execution engine. It is anticipated that any specification-conforming BPEL execution engine will be compatible with ALF.

For example, using the ALF Events and Service Flows, upon a "check-in" event, one could automatically annotate "check-in" messages for the configuration management system with information from the bug tracking and requirements tracking systems.  To accomplish this, the ALF Event Manager invokes the ALF Service Flow associated with that event, passing it all the necessary context.  Subsequently, the Service Flow executes the appropriate providers' web services to query the related information from the bug tracking and requirements tracking systems and annotates a check-in messages that is then saved to the configuration management system.  

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

ALF Component Map

The following diagram depicts the main components of the ALF framework.  The foundation for ALF is the Eclipse platform.  The Eclipse IDE provides the default client environment.  For development managers and others whose primary user interface is not an IDE, we will use the Eclipse Rich Client Platform (RCP).  For creating user interfaces for the IDE and RCP, ALF expects to leverage Eclipse frameworks such as the Eclipse Modeling Framework (EMF) and the Graphical Editor Framework (GEF) for graphical interfaces.  For development dashboard reporting, ALF expects to leverage the Business Intelligence and Reporting Tools (BIRT) project.  ALF will leverage industry standards and industry frameworks and tools to the maximum extent possible.  Being based on web services, ALF will rely on a stack of web service standards. The components in the Eclipse ALF Framework layer may be based on the generic components in the layers below, but will require additional capabilities or tailoring for ALF.  The Service Provider Interfaces provide an extensibility model for the execution layer and will include Presentation, Worklist, Relationship store, and Logging interfaces to name just a few.

 

Organization

There are many organizations with commercial offerings and technology within the scope of the project.  We will be inclusive and invite full participation in reviewing, categorizing the incoming requirements and in prioritizing the requirements. The project will use an iterative and incremental delivery plan.

The ALF project will have a major focus on customer participation. The project will find a set of initial customers/users/companies that want to develop tools on top of the framework and that these customers will use their requirements to help drive the project.  These key customers and technology partners will participate as committers, users and developers. These organizations and individuals will assist in the architecture, planning, requirements and testing of ALF.

Potential Committers

- Ali Kheirolomoom Serena (www.serena.com)
- Kevin Parker   Serena  
- Brian Carroll Serena  
- Tim Buss Serena  
- Walter Berli UBS  (www.ubs.com)
- Aniello Bove   UBS   
- Helge Scheil Niku (www.niku.com)
- Ernst Ambichl    Segue (www.segue.com)  
- Mark Patterson    Secure Software (www.securesoftware.com)
- Siva Visweswaran  Cognizant (www.cognizant.com)
- Suresh Venugopal Cognizant  
- Mohana Krishna   Cognizant  
- Emeka Obianwu BuildForge (www.buildforge.com)
- Richard Landry BuildForge  

Critical to the success of this project is participation of developers in the Application Lifecycle Management (ALM) community. We intend to reach out to this community and enlist the support of those interested in making a success of the Application Lifecycle Framework project. We also anticipate that several industry verticals will have an interest and we will therefore contact these companies and associated standard organizations. In addition, we ask interested parties to contact the ALF newsgroup to express interest in contributing to the project.