U.S. patent application number 13/790383 was filed with the patent office on 2016-06-16 for system and method for controlling the development of a software application.
This patent application is currently assigned to Software AG. The applicant listed for this patent is SOFTWARE AG. Invention is credited to Daniel ADELHARDT, Thorsten FIEBIG, Gary WOODS.
Application Number | 20160170741 13/790383 |
Document ID | / |
Family ID | 47739128 |
Filed Date | 2016-06-16 |
United States Patent
Application |
20160170741 |
Kind Code |
A9 |
FIEBIG; Thorsten ; et
al. |
June 16, 2016 |
SYSTEM AND METHOD FOR CONTROLLING THE DEVELOPMENT OF A SOFTWARE
APPLICATION
Abstract
Certain example embodiments relate to techniques for controlling
the development of a software application. The system includes an
event channel for receiving at least one event that indicates an
action performed by one of a plurality of existing development
tools used in the development of the software application, a
policy-based event engine for evaluating the at least one event and
for initiating at least one action of one of the plurality of
existing development tools in accordance with at least one policy,
and a repository, for storing at least one artifact to define an
architecture of the software application. The at least one artifact
corresponds to a component of the software application and/or to a
dependency between a first component and a second component of the
software application.
Inventors: |
FIEBIG; Thorsten; (Mannheim,
DE) ; ADELHARDT; Daniel; (Bockhorn, DE) ;
WOODS; Gary; (Seeheim, GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
SOFTWARE AG |
Darmstadt |
|
DE |
|
|
Assignee: |
Software AG
Darmstadt
DE
|
Prior
Publication: |
|
Document Identifier |
Publication Date |
|
US 20130219361 A1 |
August 22, 2013 |
|
|
Family ID: |
47739128 |
Appl. No.: |
13/790383 |
Filed: |
March 8, 2013 |
Current U.S.
Class: |
717/121 |
Current CPC
Class: |
G06F 8/70 20130101; G06F
8/35 20130101; G06F 9/44 20130101; G06F 8/30 20130101 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
Foreign Application Data
Date |
Code |
Application Number |
Feb 18, 2013 |
EP |
13 155 628.4 |
Claims
1. A system for controlling the development of a software
application, wherein the system comprises: at least one processor
and a memory; an event channel configured to receive at least one
event that indicates an action performed by one of a plurality of
existing development tools used in the development of the software
application; a policy-based event engine configured to evaluate the
at least one event and for initiating at least one action of one of
the plurality of existing development tools in accordance with at
least one policy; and a repository configured to store at least one
artifact to define an architecture of the software application,
wherein the at least one artifact corresponds to a component of the
software application and/or to a dependency between a first
component and a second component of the software application.
2. The system of claim 1, wherein the policy-based event engine is
configured to initiate at least one action of the development tool
indicated by the event and/or at least one action of one of the
plurality of development tools that is different from the
development tool indicated by the event.
3. The system of claim 1, wherein the plurality of development
tools is a build script, a test script, a binary repository and/or
a source code repository.
4. The system of claim 1, wherein the component of the software
application is an implementation component and/or a third-party
component.
5. The system of claim 1, wherein the at least one action is a test
procedure, a build process, a deployment process, closing a binary
repository and/or closing a source code repository.
6. The system of claim 1, wherein the at least one event reflects
that a new component and/or dependency was added to the software
application, and wherein the policy-based event engine is
configured to determine whether the repository comprises an
artifact that corresponds to the new component and/or
dependency.
7. The system of claim 6, wherein if it is determined that the
repository does not comprise an artifact that corresponds to the
new component and/or dependency, the policy-based event engine is
configured to create a new respective artifact and for initiating
an approval workflow.
8. The system of claim 7, wherein if the approval workflow results
in the new artifact being rejected, the policy-based event engine
is configured to initiate an action of an existing development tool
to remove the corresponding component and/or dependency.
9. The system of claim 1, wherein the at least one event reflects
that a third-party component was added to the software application,
and wherein the policy-based event engine is configured to
determine whether the third-party component is compliant with the
at least one policy.
10. The system of claim 1, further comprising at least one event
generator for a corresponding existing development tool, wherein
the at least one event generator is configured to create the at
least one event and to send the at least one event to the event
channel when the corresponding existing development tool performs
an action.
11. The system of claim 10, wherein the at least one event
generator provides a function that is callable by the corresponding
development tool to create the at least one event.
12. The system of claim 10, wherein the at least one event
generator is configured to scan a state of the corresponding
development tool to create the at least one event.
13. The system of claim 1, wherein the at least one event is an
XML-based event.
14. A method for controlling the development of a software
application using a system of claim 1.
15. A non-transitory computer readable storage medium tangibly
storing a computer program comprising instructions for implementing
a method in accordance with claim 14.
16. The system of claim 11, wherein the at least one event
generator is configured to scan a state of the corresponding
development tool to create the at least one event.
Description
1. TECHNICAL FIELD
[0001] Certain example embodiments relate to a system for
controlling the development of a software application and to a
corresponding method.
2. BACKGROUND AND SUMMARY
[0002] The development of modern software applications has become a
complex challenge. This is because modern software applications are
typically comprised of a multitude of distinct software components
each performing a certain piece of functionality of the overall
software application. Accordingly, all software components of a
software application have to work together in a consistent manner
to execute a pre-defined "process", which is to be understood as a
series of steps to be executed in a specific sequence in order to
achieve an overall computing task.
[0003] Examples of such complex software applications include
applications for controlling an assembly line e.g. for the
manufacturing of vehicles, the controlling of the tasks to be
performed by individual computing systems in a flight control
system, or the calculation of vast amounts of data for scientific
purposes, such as weather forecasts or complex simulations. Another
example of such software applications are business applications.
Business applications are focused on the automatic controlling and
orchestrating of individual computing systems that perform a task
of an enterprise (so-called "business process"). Although the
overall task to be achieved may be a business-oriented task, it is
noted that the technical implementation of the underlying software
application is typically extremely complex, since it typically
spans numerous software application components distributed among
the enterprise's information technology infrastructure.
[0004] Such components of a (business) software application may
comprise e.g. implementation components (home grown code, i.e.
self-developed components) and/or third-party components (i.e.
components that are obtained from a third-party, such as open
source components, software libraries, or the like). Apparently, a
typical complex software application is comprised of a variety of
implementation components and third-party components, which have to
be properly combined. Even more complexity is added by using e.g.
Web services that are running in external environments such as the
public cloud. In addition, all these components may come with
different versions.
[0005] In such a complex development scenario, so-called
"implementation governance" becomes a key factor to minimize both
technical and legal risks. For example, when introducing
third-party components into a software application under
development, their licensing needs to be verified and the usage of
chargeable third-party needs to be done in a controlled way to keep
costs under control. Also so-called "security compliance" is an
aspect relevant for third-party components as well as for
self-developed components. Further, the development process itself
needs to be governed, i.e. it must be controlled that the
development process moves forward in a well-defined manner. For
example, source code changes should only be committed to a central
repository unless nightly builds and build verification tests are
successful. In staged integration testing environments, certain
tests have to be passed before components can enter the next
stage.
[0006] To control the above-mentioned and other technical risks,
the implementation of the software application needs to follow a
pre-specified architecture, i.e. it has to be ensured that the
(evolving) implementation of the software application only
comprises specified components and specified dependencies between
these components. Finally, also the lifecycle of the components
needs to be governed, which also needs to cover the deprecation of
components and their sun-setting. Yet another challenge is that the
architecture of a (business) application typically evolves through
the implementation, i.e. the architecture may change during the
development of the software application. To ensure that the
implementation does not violate any compliance rules, the
governance thus needs to be carried out continuously, i.e. in a
timely fashion, and needs to be flexible enough to cope with
architectural changes.
[0007] Furthermore, complex software applications are typically
developed and implemented by a huge number of software developers.
In general, Integrated Development Environments (IDE)
(http://en.wikipedia.org/wiki/Integrated_development_environment)
are known that provide a framework of IDE tools for the development
of software applications. A common IDE for the programming language
Java is for example Eclipse. An IDE typically comprises besides
basic IDE tools for build automation and debugging additionally a
central source repository. The central IDE repository comprises the
source code on which the software developers work. The source code
is typically committed as implementation components in the source
repository and deployed to the other developers. In the development
of software applications and increasing complexity a huge number of
developers work on the development of one common application and
the source code thereof.
[0008] Those skilled in the art will appreciate that controlling
the development of a complex software application is a difficult
task, while severe technical problems can arise already if one
single commitment of an implementation component in the source
repository of a developer fails (e.g. a failure in build
automation) and the incorrect source code is already deployed to
the other developers, or even to the final product, before
detection of the failure. This way, the source code of the entire
software application might be affected by failures and consequently
also the deployed software application built from the erroneous
source code. For example, consider a software application of a
process that operates an assembly line (as mentioned before) e.g.
for the manufacturing of vehicles. An incorrect implementation of
the software application could lead to a complete halt of the
assembly line or even to damages to the produced vehicles.
[0009] "Service-oriented architecture (SOA) governance" (cf. e.g.
http://en.wikipedia.org/wiki/SOA_governance) is an approach for
controlling correct operations in a SOA, including among others
ensuring that all SOA components interact properly in terms of
communication patterns, security rules, response times and/or other
performance characteristics (quality of services), ensuring that
changing a service does not impose unforeseen consequences on
service consumers (change management) and/or ensuring that services
evolve within the system only in a controlled manner (lifecycle
management). An exemplary application of general SOA governance
with a SOA registry, namely "Governance Service Registry" and a
"Process Engine" comprising a "Governance Approval Process" is
disclosed in US patent application 2011/0314439 A1. Further
lifecycle management is addressed in this document. Explicitly, a
change of a lifecycle state of a software object is detected in the
SOA registry. A "Governance Lifecycle" process for the object is
implemented afterwards, in the SOA registry. This task of the
implementation is achieved in transmitting an approval process
input to the "Process Engine". Further examples for the general use
of registries and depositories can be found in the disclosures of
US patent application no. 2009/0083268 A1 and U.S. Pat. No.
8,132,153 B2.
[0010] Contrary to SOA governance and the use of registries, US
patent application no. 2010/0324952 A1 discloses an approach for
continuously managing Governance, Risk and Compliance (GRC) within
an integrated framework. The framework comprises an "Organization
Inventory" and "Organization Risks" layer. The "Organization
Inventory" layer comprises elements such as business components,
system and applications and assets. Importantly, each asset in the
"Organization Inventory" layer comprises a control with a
respective linkage to a risk in the "Organization Risks" layer. A
risk level is periodically measured based on a risk index,
determined for each control in this disclosure. Further the GRC
approach e.g. via the use of a GRC engine can be integrated into
Cloud Computing (via integration layers) for improved governance
efficiency (cf. related US Patent application no. 2012/0011077
A1).
[0011] However, while the above-discussed prior art approaches
allow for continuous SOA governance, i.e. the controlling of the
correct operation of an already developed SOA system, the proposed
prior art systems lack a reliable and efficient way of controlling
the development of software applications in the first place. In a
further aspect, the known approaches do not address the problems of
integrating a vast variety of different development tools into an
overall development process, controlling that the individual
components of the software application are properly integrated in a
timely fashion ("continuous integration"), and controlling that the
individual components of the software application conform to a
pre-defined software architecture ("architecture governance").
[0012] It is therefore the technical problem underlying certain
example embodiments to provide an approach for controlling the
developing implementation of a complex software application in a
continuous way and to ensure that the software application conforms
to a pre-defined architecture, so that failures in the developing
application are recognized in early stages, thereby at least partly
overcoming the above explained disadvantages of the prior art. In a
further aspect, certain example embodiments aim at providing an
approach to easily integrate a wide variety of existing development
tools, so that these tools consistently work together in the
overall development of a software application.
[0013] This problem is according to one aspect solved by a system
for controlling the development of a software application. In the
embodiment of claim 1, the system comprises: [0014] a. an event
channel, adapted for receiving at least one event that indicates an
action performed by one of a plurality of existing development
tools used in the development of the software application; [0015]
b. a policy-based event engine, adapted for evaluating the at least
one event and for initiating at least one action of one of the
plurality of development tools in accordance with at least one
policy; and [0016] c. a repository, adapted for storing at least
one artifact to define an architecture of the software application,
wherein the at least one artifact corresponds to a component of the
software application and/or to a dependency between a first
component and a second component of the software application.
[0017] Accordingly, the embodiment defines a comprehensive control
system for enabling a proper, reliable, timely and
architecture-conformant control over the development of software
applications. As mentioned before, nowadays complex software
applications (such as business applications) are implemented by a
plurality of software developers which typically use a vast variety
of different development tools for the individual tasks of the
overall development process. The software architecture shows
similar complexity and is defined by software/implementation
components that are related to each other via dependencies. The
implementation components and dependencies therebetween have to be
controlled in a continuous way for the early detection of policy
violations, such as violations of the specified architecture.
[0018] Importantly, certain example embodiments propose an
event-driven system comprising an event bus and a policy-based
event engine exercising centralized control over the development of
software applications. Explicitly, all activities that are
triggered by the development tools are observed in the event
channel and fed into the policy-based event engine. As one
important advantage over the prior art, the event-driven approach
allows for the addressed timely detection of anything going on in
the development tools, comprising the detection of failures or
policy violations in the very beginning. Furthermore, the
policy-based event engine of certain example embodiments is not
only capable of analyzing events triggered by the development
tools, but also capable of triggering certain actions of the same
or a different development tool in response, which results in a
comprehensive control of the existing development tool chain.
Certain example embodiments further provide an easy integration of
any type of existing development tool, since the tool simply has to
be "hooked" into the event bus.
[0019] The above-described system further comprises a repository
which is adapted for storing at least one artifact to define an
architecture of the software application, wherein the at least one
artifact corresponds to a component of the software application
and/or to a dependency between a first component and a second
component of the software application. Accordingly, providing a
repository in which the desired architecture of the software
application to be developed is defined allows for a reliable
evaluation whether the actual implementation of said software
application (as it is performed by means of the development tools)
actually conforms to the desired architecture.
[0020] In the following a plurality of scenarios related to
failures in the development of software applications are briefly
addressed to provide explicit examples and to underline the
importance of the above-mentioned advantages.
[0021] Considering two components of a software application with an
invalid dependency, it has to be ensured that this dependency is
detected early on to avoid an inclusion or commitment of this
incorrect dependency on the source code level. Besides software
architecture, developmental processes, such as build automation,
code repository management and automated deployment have to be
considered in software applications. Considering further the build
automation, e.g. the source repository should be closed whenever
there is a build problem. Hence the commitment and deployment of an
undesired or error-prone component or dependency can be
prevented.
[0022] The development of the implementation is controlled
automatically and continuously with the policy-based event engine
of certain example embodiments to avoid the addressed failures and
to allow for early detection of problems. This policy-based event
engine is importantly adapted for evaluating at least one event in
accordance with at least one policy, and further adapted for
initiating at least one action of the development tool referenced
by the event.
[0023] For example, the policy-based event engine might relate to
the control of the detection of a new software component. The event
("Detection") received via the event channel is evaluated in the
policy-based event engine. One exemplary policy for such evaluation
("architecture compliance check", i.e. "is the component conformant
with the architecture") is related to the verification whether the
software component is in accordance with the software architecture
defined by the repository's artifacts. Depending on the result of
the evaluation of the policy, an appropriate action may be
triggered. For example, the new component is approved if its
conformance with the architecture is confirmed. In the other case,
i.e. if it is evaluated that the new component does not conform to
the architecture, the new component is rejected and certain actions
are triggered to assure that the violation can be fixed (e.g. the
source repository relating to the component in question can be
closed, or an alert message, such as an email, can be sent to a
developer who is in charge of the component).
[0024] In a further aspect, the policy-based event engine is
further adapted for initiating at least one action of the
development tool indicated by the event and/or one of the plurality
of development tools which is different from the development tool
indicated by the event. Accordingly, certain example embodiments
allow not only to trigger a certain action of the particular
development tool which issued an event itself, but also
additionally or alternatively to trigger another one of the various
development tools. In particular according to the latter aspect,
the present system is thus capable of controlling the entire
development tool chain involved in an arbitrarily complex
development process.
[0025] For example, the plurality of development tools may be
selected from the group comprising a build script, a test script, a
binary repository and/or a source code repository, and the at least
one action may be selected from the group comprising a test
procedure, a build process, a deployment process, closing a binary
repository and/or closing a source code repository. Accordingly,
development tools may include IDE tools, providing various aspects
of software application development (such as software architecture
and/or build automation). The execution of a development tool
results in an according action. In general it is plausible that not
just the development tool referenced by the event is executed, but
other tools as well. Typically software components run through a
"lifecycle" with distinct developmental stages. Considering the
example of new implementation components, mentioned further above,
in a first stage a new integration component is detected and the
IDE tool (build script) with the action (build process) is
triggered. This action might cause the creation of a new software
component and deployment in the source code after successful build.
The implementation component enters the approved stage.
[0026] As already indicated above, the at least one component of
the software application may be selected from the group comprising
an implementation component (i.e. a self-developed component, such
as "home grown" code) and/or a third-party component (i.e. a
component obtained from a third party, such as open source
components, binary components, software libraries, or the
like).
[0027] In yet one further aspect, the at least one event reflects
that a new component and/or dependency was added to the software
application, and wherein the policy-based event engine is adapted
for determining whether the repository comprises an artifact that
corresponds to the new component and/or dependency. Accordingly, it
can be easily checked whether a component, which was newly added to
the software application by one of the development tools, was
actually planned, i.e. whether it conforms to the architecture of
the application. If it was planned, the repository already
comprises a corresponding artifact.
[0028] In one further aspect, if it is determined that the
repository does not comprise an artifact that corresponds to the
new component and/or dependency, the policy-based event engine is
adapted for creating a new respective artifact and for initiating
an approval workflow. Accordingly, if no corresponding artifact is
present in the repository for the newly added component or
dependency, the addition of the component or dependency does not
have to be forbidden altogether, but an approval process can be
started in order to determine whether the newly added component or
dependency should be kept in the software application.
[0029] In one further aspect, if the approval workflow results in
the new artifact being rejected, the policy-based event engine is
adapted for initiating an action of an existing development tool to
remove the corresponding component and/or dependency. Accordingly,
if it turns out that the newly added component/dependency did not
pass the approval workflow, certain example embodiments reliably
ensure that the undesired component/dependency is, preferably
immediately, removed from the software application. This way, it is
ensured that the software application stays free of erroneous
aspects in a timely fashion.
[0030] In one further aspect, the at least one event reflects that
a third-party component was added to the software application, and
wherein the policy-based event engine is adapted for determining,
by means of the at least one policy, whether the third-party
component is compliant with the at least one policy. This includes
e.g. the evaluation whether the third-party component is properly
licensed or whether the third-party component introduces a security
vulnerability. Accordingly, it can be efficiently and reliably
controlled that only proper code is integrated into the software
application to be developed at any time. Also, new policies can be
added to the system of certain example embodiments to dynamically
to cope e.g. with new acceptance tests, etc. for third-party
products.
[0031] As it is apparent from the above, the repository of certain
example embodiments provides a further central system component of
the policy-based event engine comprising artifacts that define the
intended architecture of the software application. An artifact may
represent different types of components and/or their dependencies.
For example, jar files, Java packages or Java sources and/or third
party jars and/or third party products can be considered as types.
Further, artifacts can have different lifecycle states. Artifacts
typically comprise information such as a name and/or type to
uniquely identify a component in the repository.
[0032] In yet another aspect, the system further comprises at least
one event generator for a corresponding existing development tool,
wherein the at least one event generator is adapted for creating
the at least one event and for sending the at least one event to
the event channel when the corresponding existing development tool
performs an action. Accordingly, the system of certain example
embodiments can be extended with at least one event generator,
integrated as an interface between the at least one development
tool and the governance event channel. The event generators are
responsible for the generation of events and/or sending events to
the governance event channel, thereby allowing an easy and reliable
integration of existing development tools into the system of
certain example embodiments.
[0033] In one aspect, the at least one event generator provides a
function that is callable by the corresponding development tool to
create the at least one event. Accordingly, the event generator
might offer a so-called API (application programming interface)
into which the corresponding development tool can hook itself in
order to be integrated into the overall control system.
[0034] Additionally or alternatively, the at least one event
generator is adapted for scanning a state of the corresponding
development tool to create the at least one event. Accordingly, in
this aspect the development tool is passively integrated into the
overall control system without having to be adapted at all.
[0035] In another aspect, the at least one event is an XML-based
event, which allows for a particularly easy and flexible definition
of the contents of the events communicated within the system of the
present invention.
[0036] Certain example embodiments are also directed to a method
for controlling the development of a software application using any
of the above-disclosed systems.
[0037] Furthermore, certain example embodiments also provide a
computer program comprising instructions for implementing the
above-described method.
3. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] In the following detailed description, presently preferred
embodiments are further described with reference to the following
figures:
[0039] FIG. 1: A schematic representation of a system for
controlling the development of a software application with a
policy-based event engine as central control component in
accordance with one embodiment; and
[0040] FIG. 2: An exemplary life cycle for new implementation
components comprising different life cycle states in accordance
with one embodiment.
4. DETAILED DESCRIPTION
[0041] In the following, a presently preferred embodiment is
described with respect to a system 1 for controlling the
development of a software application schematically shown in FIG.
1. As can be seen, certain example embodiments propose a system 1
with a central policy-based event engine 50 (hereinafter also
interchangeably referred to as "Governance engine") and an event
driven approach allowing for an easy integration of existing
development tool (such as IDE tool) chains 20 into the event-based
control system 1.
[0042] As illustrated in FIG. 1, the different IDE tools 20 like
build scripts, binary repository and source repository are talking
to event generators 30. The event generators 30 are creating events
and send those events to the governance event channel 40 (also
referred to as "event channel"). The generated event stream is
consumed, i.e. received, by the governance engine 50. The
governance engine 50 has the capability of evaluating policies 52
on the event stream. Note that, as already mentioned further above,
policies 52 may be provided that operate on a single event, on a
continuous stream of incoming events (i.e. on a series of events
arriving at a constant frequency), or even on a stream of discrete
events arriving sporadically on the event channel. Accordingly,
certain policies may fire when a single event of interest is
detected, when a certain threshold of multiple events occurs within
a certain period of time, or when a certain pattern is detected
within the stream of events. Additionally, the policies 52 can look
up information from the governance engine 50 repository 54. The
governance engine 50 policies 52 can in turn trigger arbitrary
actions affecting the integrated IDE tools 20. For example, the
policies 52 can initiate a build process or can trigger the closing
of a source repository. Although the policies 52 are shown in FIG.
1 as distinct entities from the repository 54, the policies 52 may
also be stored and managed within the repository 54. The set of
policies 52 can be extended.
[0043] Besides these policies 52, in one preferred embodiment the
repository 54 stores the artifacts of the software architecture of
the software application, which is meta-data for the software
components and the dependencies between them. The component
artifacts can represent all kinds of software components comprising
single 3.sup.rd party jars and/or 3.sup.rd party products. Also
source components like Java packages or source files can be
represented via component artifacts. The component artifacts might
carry the information to uniquely identify a component in the
source or binary repositories. As one example, dependency artifacts
can be identified based on the components and/or the dependency
type.
[0044] Preferably, the repository 54 has a classification system to
add more semantics to the artifacts. Classifications can be used to
distinguish between different types of component artifacts or
dependencies. As one example, artifacts may be classified based on
one or more taxonomies managed in the repository. For example, the
different types of components may be managed in a taxonomy and the
repository may allow to define arbitrary taxonomies that are needed
to represent the semantics/purpose of a component/artifact.
[0045] Further, in another embodiment artifacts can have different
versions and/or different lifecycle states. The lifecycle
management capabilities comprise the definition of lifecycle states
and/or lifecycle stages (i.e. groups of lifecycle states), which is
important to model a stage development scenario. Policies 52 can be
attached to state transitions to ensure certain consistency
constrains. Since the policies 52 of the governance engine 50 can
trigger arbitrary actions, approval workflows can be initiated on a
state change. Concerning this aspect of lifecycle management, the
system of certain example embodiments may generally provide
functionalities as disclosed in European patent No. 1 898 345 B1 of
applicant titled "system for managing the lifecycle of a service
oriented architecture".
[0046] The set of component artifacts is exemplary defined based on
the architecture of the business application. The component set can
be updated to cope with architectural changes. Changes of the
component set are governed (also referred to as controlled) via
policies 52. An example for a common policy 52 rejects the
introduction of new 3.sup.rd party components that have not passed
the necessary licensing checks. Other policies 52 can be more
specific to the business application. In a preferred embodiment
there could be policies 52 to ensure that certain components are
not directly referenced but only through a certain interface.
[0047] In one preferred embodiment, on the governance event channel
40 there are process related events like those indicating a new
successful build or a failing tests. Other events are indicating
component or dependency updates. These events are for example
relevant for the architecture continuous governance or control. If
there is an event indicating the creation of a new component
policies 52 are checking the validity of the newly detected
component. First, the check if there is an artifact in the
repository matching the new component. If this is the case the new
component is a valid part of the architecture. If not, a new
artifact is created that runs through a configurable lifecycle to
become part of the approved architecture. An exemplary (simple)
governance lifecycle is shown in FIG. 2.
[0048] As indicated in FIG. 2, when a new component is detected, an
according event "NewComponent" is sent on the event channel 40. The
policies 52 processing this event create a new artifact in the
repository 54 and verify the aspects described herein. If the
policies or the approval are failing, the artifact is moved to the
lifecycle state "Rejected". Otherwise, it is moved to the lifecycle
"Approved", which indicates that the artifact is valid and that the
corresponding component is allowed to be part of the software
application. These lifecycle state changes may also result again in
events, but in the simple case this is not necessary. Updates
and/or deletions of components may be handled accordingly. This
means if an event is detected indicating a component update or
deletion, its artifact in the repository 54 is processed
accordingly.
[0049] Dependency artifacts can be processed in a similar way in
one aspect of certain example embodiments. If there is an event
indicating a new dependency it is checked if there is already a
corresponding artifact in the repository 54. If not, a new one is
created and moved through a governance lifecycle. Corresponding to
the component lifecycle the dependency lifecycle is configurable.
The state transitions of the dependency lifecycle can have attached
policies 52 including polices 52 triggering an approval process. If
a dependency artifact reaches an "Approved" state it is added to
the architecture. If it reaches a "Rejected" state, actions are
triggered to remove the dependency from the implementation.
Dependency updates and/or deletions are preferably processed
accordingly.
Preferred Implementation
[0050] The implementation of an exemplary embodiment preferably
comprises: [0051] Governance event channel 40 and event generators
30 [0052] Governance engine 50 including governance policies 52 and
repository 54 [0053] Action triggers 10
[0054] The implementation of IDE tools 20 is not in scope of
certain example embodiments, rather the integration of the
continuous control into existing IDE tools 20 as one aspect of
certain example embodiments.
Governance Event Channel
[0055] The governance event channel 40 can be preferably
implemented with enterprise service bus (ESB) technology or with
the Apache Camel enterprise integration framework. The Apache Camel
framework supports content based routing of messages. Apache Camel
offers multiple transport methods that can be leveraged for sending
messages holding governance events.
[0056] According to the event driven architecture paradigm the
event messages preferably comprise a header and/or a body. The
header comprises the event type. The event type helps to
distinguish different types of governance events. For example the
events indicating changes of the component or their dependencies
have a dedicated type to distinguish them from development process
events. This distinction makes it easier to route the events to the
dedicated policies 52 and to process them within the governance
event stream. The event body holds the event payload which is
dependent on the event type. The following sample shows a
simplified XML event message that indicates a build error.
TABLE-US-00001 <event> <header>
<type>BuildFailure</type> </header> <body>
<build-number>6798</build-number> <build-results>
http://host:8080/job/INMJ_trunk_continuous/6798/ console
</build-results> </body> </event>
[0057] The header of the event comprises as one example the event
type and the body provides details about the build failure like the
build number and a link to obtain the detailed build results.
[0058] Architecture related events preferably hold the details
about the affected components and their dependencies. The following
message shows an example for an event indicating a new
dependency.
TABLE-US-00002 <event> <header>
<type>NewDependency</type> </header> <body>
<dependency> <source type="jar">
http://host:8080/binary-repository/notification.jar </source>
<target type="jar">
http://host:8080/binary-repository/mail.jar </target>
</dependency> </body> </event>
[0059] An exemplary and simplified XML message shows the event
header with the event type and the body that holds the information
about the source and the target of the dependency. Source and
target of the dependency are identified via URLs pointing to the
binary repository. The new dependency is detected between a home
grown jar and 3.sup.rd party jar file.
[0060] Dependencies between Java packages can be represented
correspondingly. The following sample shows an event indicating a
new dependency between two Java packages.
TABLE-US-00003 <event> <header> <type>New
Dependency</type> </header> <body>
<dependency> <source-type="java-package">
com.example.notification </source>
<targettype="java-package"> javax.mail.internet
</target> </dependency> </body>
</event>
Event Generators
[0061] In one preferred embodiment, the IDE tools 20 do not
directly create event messages that can be sent through the
governance event channel 40. This gap can be bridged by the event
generators 30. Several types of event generators 30 are needed to
deal with the different types of IDE tools 20 and their
capabilities. Some of them already support the creation of events
that just need to be translated into the event messaging format of
the governance event channel 40.
[0062] The following sample shows the pseudo code of a function
that can be called by a script that is triggered by the source
repository on a commit of a source file change.
TABLE-US-00004 void extract-new-dependency(File changedFile) {
Package sourcePackage = changedFile.getPackage( ); Collection
changedLines = changedFile.getChangedLines( ); foreach(Package
targetPackage in extractImport(changedLines)) { Event event = new
NewDependencyEvent(sourcePackage,targetPackage);
GovernanceEventChannel.sendEvent(event); } }
[0063] Preferably, the input of the function is a File object
holding the changed file including all the changed source lines.
From these changed lines the function extracts the Java imports.
For each detected import it creates a "NewDependency" event and
submits it to the governance event channel 40.
[0064] Other IDE tools 20 are harder to integrate, since their
state needs to be scanned to determine if a certain event has
happened. This kind of integration problem can be solved by
applying the well-known enterprise integration patterns. The Apache
Camel framework offers a comprehensive implementation for the
enterprise integration patterns which makes it a good candidate for
implementing the governance event channel and the event generators
30.
Governance Engine
[0065] In a preferred embodiment, the core components of the
governance engine 50 are the repository 52 and the policy engine
that supports the execution of polices 52 on the governance event
channel 40 and on the repository 54 content.
Repository
[0066] The repository 54 preferably manages the artifacts for
representing software components and their dependencies. The
repository 54 can comprise various kinds of artifacts including
those representing jar files, Java packages or Java sources. The
following sample shows the simplified XML representation of an
artifact representing a Java package.
TABLE-US-00005 <artifact> <name>Notification
package</name> <type>java-package</type>
<uri>com.exorg.artifacts/java-package/com-example-
notifcation</uri>
<component>com.example.notification</component>
<lifecycle-state>approved</lifecycle-state>
</artifact>
[0067] Exemplary, the artifact has a display name that can be
internationalized. The artifact type distinguishes between the
different kinds of artifacts. Here the powerful classification
mechanism of the repository 54 can be applied. The classifications
are done based on taxonomies that also stored in the repository
54.
[0068] For example, the artifact's URI is the unique identifier.
The represented software component is referenced via the component
element. Artifacts can be versioned and assigned to a state of
lifecycle that is also maintained in the repository 54. In this
example, the lifecycle state is "approved".
[0069] The governance engine 50 repository 54 provides powerful
query capabilities to retrieve the artifacts for a given software
component or vice versa.
[0070] The artifacts can have dependencies. The following XML
fragment shows an import dependency between two Java package
artifacts.
TABLE-US-00006 <dependency>
<source>com.exorg.artifacts/java-package/com-example-
notifcation</source>
<target>com.exorg.artifacts/java-package/com-example-
mail</target> <type>import</type>
</dependency>
[0071] Preferably, the source element comprises the URI of the
artifact representing the dependency source. The target element
points to the target artifact. The dependency type classifies the
dependency as an import dependency. The dependency classifications
are done based on the taxonomies stored in the repository 54.
[0072] Besides import dependencies also containment dependencies
can be represented. The following dependency shows that the
notification package belongs to the notification jar.
TABLE-US-00007 <dependency>
<source>com.exorg.artifacts/jar/notifcation</source>
<target>com.exorg.artifacts/java-package/com-example-
notifcation</target> <type>contain</type>
</dependency>
[0073] The query capabilities of the repository 54 allow to
efficiently retrieving dependencies pointing to an artifact as one
example.
Repository Policies
[0074] In one aspect, to govern or control the content of the
repository 54 it supports policies 52. The policies 52 can be
defined via a domain specific language (DSL) or a generic
programming language like Java. The resulting flexibility allows to
perform arbitrary checks and to trigger arbitrary actions via
policies 52 including the start of a workflow process or starting
build processes, tests or automatic deployments. The following
sample shows pseudo code for a policy 52 ensuring that a package is
only contained in a single jar.
TABLE-US-00008 PackageCheckPolicy { boolean condition(Dependency
newDep) { if(newDep.getSource( ).getType( ) != "jar") or
newDep.getType( ) != "contains") { return false; } Collection deps=
Repository.getDendenciesByTarget(newDep.getTarget( ));
foreach(Dependency dep in deps) { if(dep.getSource( ).getType( ) ==
"jar" and dep.getType( ) == "contains") { return true; } } return
false; } void action(Dependency newDep) {
policy-validation(newDep); } }
[0075] Exemplary, the sample policy 52 is fired whenever a new
dependency is added to the repository 54. If the source of the new
dependency is ajar artifact and the dependency has the type
"contains", it checks if there is already a containment dependency
in the repository 54 pointing to the same Java package. In this
case the policy results in a policy 52 violation that rejects the
new dependency to the repository 54.
Event Policies
[0076] In addition to policies 52 considering the repository 54
content polices are needed directly operating on the governance
event channel 40 in one preferred embodiment. These policies 52 are
executed by the policy engine 50 listening on the governance event
channel. The policies 52 can be specified via a domain specific
language (DSL) or generic programming language like Java. The
policies 52 can execute arbitrary actions including storing new
actions in the repository, triggering IDE tools or starting
workflow processes. The following sample shows a policy reacting on
a build error by locking the source repository 54.
TABLE-US-00009 BuildErrorPolicy { boolean condition(Event event) {
if(event.getType( ) == "BuildError") { return true; } return false;
} void action(Event event) { lockSourceRepository( ); } }
[0077] The policy 52 is triggered on an event on the governance
event channel 40. If the event type indicates a build error the
condition function returns true. The action of the policy 52 locks
the source repository 54 via the according action trigger 10.
Triggering Actions
[0078] Preferably, the action triggers 10 invoked by the policies
52 interact with the IDE tools 20. Simple action triggers 10 just
execute scripts for initiating builds or test executions. These
kinds of operations can also be invoked by not directly starting a
script but by interacting with a continuous integration (CI) server
such as Jenkins (http://jenkins-ci.org/) or Hudson
(http://hudson-ci.org/). Jenkins even supports the triggering of
build jobs by sending HTTP request to a certain URL. More advanced
actions are controlling the source and binary repository
repositories.
[0079] The automatic deployment can be triggered via simple scripts
or via dedicated deployment tools. The automated deployment
supports single jars as well as complete images deployed to a cloud
server.
Comparison to Prior Art Approaches
[0080] In the following, certain example embodiments are compared
to conventional techniques:
Continuous Integration
[0081] The continuous integration (CI) is about organizing the
implementation work of a team
(http://martinfowler.com/articles/continuousIntegration.html). The
idea is to integrate their work frequently to report problems as
early as possible to the team members. The integration is verified
by a build that is automatically tested. The CI key practices are:
[0082] Maintain a Single Source Repository. [0083] Automate the
Build [0084] Make Your Build Self-Testing [0085] Everyone Commits
To the Mainline Every Day [0086] Every Commit Should Build the
Mainline on an Integration Machine [0087] Keep the Build Fast
[0088] Test in a Clone of the Production Environment [0089] Make it
Easy for Anyone to Get the Latest Executable [0090] Everyone can
see what's happening [0091] Automate Deployment
[0092] Several CI tools and products have been implemented for
supporting the CI practices, comprising: [0093] Hudson
(http://hudson-ci.org/) [0094] Jenkins (http://jenkins-ci.org/)
[0095] Neither the CI approach nor the CI tools cover governance
aspects like 3.sup.rd party component management or a policy based
architectural governance.
Binary Repositories
[0096] Binary repositories are also belonging to the CI enabling
tools. Their purpose is to manage executables (binaries) and to
share them across teams. The binary artifacts that can be managed
include 3.sup.rd party components as well as build results. The
binary repository features also include dependency management and
licensing checks. Example products and tools are: [0097] Sonatype
Nexus (http://www.sonatype.com/) [0098] Artifactory from JFrog
(http://www.jfrog.com/home/v_artifactory_opensource_overview)
[0099] These products offer certain governance capabilities and can
be easily integrated with other IDE tools. Nevertheless they do not
provide advanced policy based governance capabilities. They also do
not offer any event driven integration with IDE tools to enable
continuous governance.
Continuous Delivery
[0100] Continuous delivery is another software development strategy
for optimizing the deliver process of business applications. The
products and tools in this area covering the automation of the
whole development cycle including build, tests and deployment.
Architectural governance is not covered.
Architecture/Implementation Governance
[0101] Architecture governance is an aspect of enterprise
architecture as suggested by the architecture framework of the open
group (http://www.opengroup.org/togaf/). It can be applied on
single products as well as on the IT environment of a whole
enterprise. The implementation governance makes sure that an
implementation is compliant with the specified architecture.
Performing continuous architecture governance via an event driven
architecture is a new approach and not covered by the architecture
framework of the open group.
SOA Governance
[0102] SOA governance (as already mentioned above) is a specific
area of enterprise architecture. It is about keeping the control
over the assets and artifacts of a SOA (Service Oriented
Architecture). Several tools have been developed for supporting SOA
governance. Closely related are the policy enforcement point
products Layer7 and Progress (http://www.layer7tech.com/,
http://web.progress.com/) and the SOA registry/repository products
CentraSite, Systinet, WSRR, SOA Software, and Oracle Enterprise
Repository (http://www.centrasite.com/,
http://www8.hp.com/us/en/software/software-product.html!compURI=tcm:245-9-
36884, http://www-01.ibm.com/software/integration/wsrr/#,
http://www.soa.com/,
http://www.oracle.com/technetwork/middleware/repository/overview/index.ht-
ml) that can interact with policy enforcement points. Although
these products offer certain capabilities that are necessary to
implement continuous governance, they do not offer any event driven
continuous governance approach. Moreover the supported governance
does not cover the development process of modern business
applications.
Event Driven Architecture
[0103] The event driven architecture (EDA) is an architectural
paradigm that is based on event processing that allows to loosely
couple software components
(http://en.wikipedia.org/wiki/Event-driven_architecture). An event
driven architecture consists of: [0104] Event generators [0105]
Event channels [0106] Event processing [0107] Event driven actions
[0108] The EDA concept does not cover any governance related
aspects, but provides the basis for the continuous governance
approach disclosed by this embodiment.
SUMMARY
[0109] The concept of certain example embodiments relates to a
system, preferably for a (software) development system. But it can
also be used wherever business processes are affected by ongoing
changes (cycles) that need to be controlled as a whole. Software
development (and software integration in general) comprises a lot
of disjoint activities, like watching for changes in the source
control system and/or checking the results of automated tests
and/or integrate the latest used 3.sup.rd party software and/or
guarantee ongoing successful builds, etc. Guarding all of these
steps, plus having a concept of the overall connection between
them, is very hard to control manually. But since these are usually
disjoint processes, integration is not easy. The state-of-the-art
solution involves the usage of scripting and tedious
synchronization across multiple platforms, which makes the
architecture very vulnerable. Certain example embodiments propose a
system, which has a "Governance Event Channel" and a "Governance
Engine" (including a repository handling policies) as the active
part to control and change the flow accordingly. All other
components can use special clients (Event Generators) for
communication.
[0110] Certain example embodiments hence propose an approach to
merry an event bus and an active, policy-driven repository engine.
All this has a minimal side-effect on the governed processes. New
processes can be added seamlessly without increasing the
complexity. In comparison to existing systems known from prior art,
the proposed solution is more robust, flexible and scalable.
[0111] It will be appreciated that as used herein, the terms
system, subsystem, service, engine, module, programmed logic
circuitry, and the like may be implemented as any suitable
combination of software, hardware, firmware, and/or the like. It
also will be appreciated that the storage locations herein may be
any suitable combination of disk drive devices, memory locations,
solid state drives, CD-ROMs, DVDs, tape backups, storage area
network (SAN) systems, and/or any other appropriate tangible
non-transitory computer readable storage medium. Cloud and/or
distributed storage (e.g., using file sharing means), for instance,
also may be used in certain example embodiments. It also will be
appreciated that the techniques described herein may be
accomplished by having at least one processor execute instructions
that may be tangibly stored on a non-transitory computer readable
storage medium. For instance, a SOA may include processing
resources including, for example, one or more processors, a memory,
disk or other transitory or non-transitory storage, etc., which
maybe configured to cooperate in executing a method of the type
disclosed herein. The engines described herein may in certain
example embodiments be controlled by and/or include processing
resources such as, for example, at least one processor, a memory,
transitory and/or non-transitory computer readable media, etc.
[0112] While the invention has been described in connection with
what is presently considered to be the most practical and preferred
embodiment, it is to be understood that the invention is not to be
limited to the disclosed embodiment, but on the contrary, is
intended to cover various modifications and equivalent arrangements
included within the spirit and scope of the appended claims.
* * * * *
References