ALF/architecture/ALF Architecture

ALF Wiki Home

Introduction

An Application Lifecycle is the continuum of activities required to support an enterprise application from its initial inception through its deployment and system optimization. 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	Borland CaliberRM, Serena RTM, Telelogic DOORS etc.
Change & Configuration Management	Rational ClearCase, Serena ChangeMan etc.
Version Control	CVS etc.
Application Modeling	Borland Together, Rational Rose etc.
Software Development	Eclipse, IBM WebSphere Studio, Microsoft Visual Studio etc.
Defect Tracking	Bugzilla Mantis, SerenaTeamTrack etc
Quality Assurance	Mercury TestDirector, Segue SilkCentral etc.
Deployment	IBM Tivoli, Macrovision, InstallShield etc.
Application Security	CA Netegrity, Entrust, Secure Software CodeAssure etc.
Project Portfolio Management	Niku Clarity etc.

The number of possible combinations of a set of n integration points taken 2 at a time is given by n(n-1)/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 quickly becomes unmanageable.

To effectively manage the application change across the lifecycle, these various product silos and toos need to be integrated.

Daniel Gross: This sentence appears ambiguous to me. Does application change refer to: the changes that are required to be made in different ALM tools, when ALM tool requirements change, and that need to be managed effectively, in particular when changes propagated (or ripple) throught the integration infrastructure, to other integrated ALM tools -- this is a change of the ALM tool design and software code the changes of data and objects within application, and how these need to be propagated to other ALM tools, which needs to be managed effectively -- this is a change in data stored in ALM tools, that has to be propagated to other tools. I was also wondering why the above refers to the "management of change", why not more generally, to deal with change

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.

Having learned valuable lessons from previous industry initiatives such as IBM AD Lifecycle, Guide Repository Model, and CDIF, we have concluded that:

• Point-to-Point integrations are costly to develop and maintain
• SOA-based Architecture provides a platform-agnostic foundation for multi-vendor integration and service orchestration
• Loose-coupling provides the appropriate level of abstraction and facilitates cross-product integration and interoperability
• We need to provide a low-barrier for entry and minimize the need for a universal meta model as a gating factor for “getting started”

The ALF Solution

ALF solves 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. It allows a single integration on the central node. The central node then carries out communication with other ALM applications through orchestration of their corresponding web services. While there is still a need to map and transform data from the various tools within the central node this is much simpler than many direct integrations since it is achieved using a common infrastructure across all tools. This allows commonalities to be exploited and encouraged. In addition, it provides a delivery point and thus motivation to create common vocabularies.

ALF delivers the following:

• Eclipse IDE plug-ins for Software Developers building ALM-based solutions
• An SOA-based cross-tool runtime communication infrastructure including Event Manager and WSBPEL Service Flow components deployable at the desktop or server
• Conformance rules for varying levels of participation through a layered extensibility API
• Community enablement to develop common domain-specific event and service vocabularies as needed for improved interoperability

Eclipse ALF can be thought of as “SOA for Development”, and as such, incorporates the best features of SOA. ALF consists of three main components:

1. ALF Event Manager
2. ALF Service Flow Engine
3. Provider Services

In addition to these main components, ALF provides a number of Eclipse IDE plug-ins to help build, deploy and manage ALF solutions. ALF also defines an extensible set of Event and Service Vocabularies and provides a number of Service Provider Interfaces (SPI) allowing a number of avenues for participation, cooperation, and extension.

Nomenclature used in this document

The following terminology will be used throughout this document:

ALF – The Application Lifecycle Framework is a collection of capabilities that support the interaction and interoperability of application development tools. Tool – An application used by human participants in the software development process. The notion of “tool” is quite encompassing, including Requirements tools, UML modeling tools, code generation tools, database design tools, code checking tools, test tools, BUILD tools, deployment tools, etc. Toparticipate in ALF a tool is expected to emit web service events and/or provide web service interfaces to expose its operations.

Context – A tool is assumed to be operating in a logical environment we call a “Context”. The notion of Context includes who is using the tool (or on whose behalf the tool is being used), and under what circumstances is the tool being used. That is, is being operated by a human or has it been invoked under the control of a ServiceFlow, or sequence of nested ServiceFlows.

Object – A development artifact (e.g. an entity or relationship) that is managed by or operated on by a tool. For example, for a Requirements tool, objects are likely to be Requirements and related artifacts. In addition, a relationship between a Requirement object and a document would also be an object. For a UML class diagramming tool, the objects might be a class diagram, a class, a class relationship, etc. For a configuration management tool, an object might be a file or a document.

Event – (1) A significant change to an object within a tool constitutes an Event. Tools emit events and the ALF Event Manager receives them. It is also possible for a ServiceFlow to emit an event message. (2) The web service message that conveys the notification of the event from the tool to the EventManager is also referred to as an Event.

ALF Event Manager – An intermediary or broker that receives Events emitted by tools and launches the appropriate action or response. The Event Manager is like a filter and router. It examines the basic data about an Event and determines the appropriate action to take for that Event Action – A generic term for a number of possible responses to an Event. A common Action is to launch a ServiceFlow.

Launch – To invoke or cause something to happen. A typical Action is to invoke a ServiceFlow, passing all the data contained in the triggering Event.

ServiceFlow – An orchestration (i.e. coordination) of a set of tools to perform some coherent function. For ALF, the orchestration is described using WS-BPEL. (Business Process Execution Language).Tools often operate with the context of a ServiceFlow (that is, they are invoked as a step in the ServiceFlow).

ALF ServiceFlow Engine – An engine (i.e., a software process) that, when invoked, executes a WSBPEL orchestration, i.e., a ServiceFlow.

High level Architecture

ALF Events and the ALF Event Manager

An ALF Event is a web service message sent from the tool to the ALF Event Manager. ALF provides an event vocabulary covering common concepts. Events are expressed as WSDL contracts. While the fundamental ALF Event is fairly generic providing only context information, ALF Events can be extended to encapsulate a richer event vocabulary. ALF provides a concept of Event Type allowing the definition of Event Vocabularies. Event Vocabularies allow Tools from multiple vendors to emit the same rich event type thus making the operation of ALF potentially independent of the particular tool. ALF Event management is based upon a configurable dispatch. Tools that can emit ALF Events register themselves and the events that they emit with the Event Manager. An administrator configures which ALF Service Flows will run as a result of that event. At runtime, the Event Manager receives the event and invokes the appropriate ALF Service Flow passing it the Event data.

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. ALF provides a common service standard for the conversations between tools to provide a framework that leads to a homogenous and consistent overall model. ALF specifies the overall style, organization, and constraints. This defines the ALF Service Vocabulary. ALF provides a framework to allow the base Service Vocabulary to be extended to define richer subject matter specific common services.

ALF Service Flows and the ALF Service Engine

Provider web services registered with the ALF framework can be orchestrated using ALF Service Flows. ALF uses the OASIS Web Services Business Process Execution Language (WS-BPEL) based Engine to do this. ALF Service Flows are defined using WS-BPEL, an XML based programming language specifically designed to describe interactions between Web Services and facilitate the mapping of data between them.

An Example

Using an Eclipse-plug-in for an issue tracking system, a user enters an issue. The user continues to perform some analysis on the issues in that system and he classifies it with a Type, Priority and Severity Completion of this classification triggers an event which launches an ALF Service Flow to evaluate the issue and determine if it should be:

Added as a new requirement in the Requirement management system, or
Handled as a task in current projects and added to the project management system

[Note: In this scenario all human interaction is done within the respective systems. The ALF Service Flow provides the link between these systems.]

References

Wikipedia: Enterprise integration

Enterprise Integration Patterns: [1]