InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Article: Beyond SOA, a New Type of Framework for Dynamic Business Applications - Part II

Posted by Jean-Jacques Dubray on Jul 08, 2008

Sections
Operations & Infrastructure,
Enterprise Architecture,
Development,
Architecture & Design
Topics
Application Servers ,
SOA ,
Architecture ,
Enterprise Architecture ,
Business Process Management ,
Domain Specific Languages ,
Composite Application
Tags
JBoss ,
Java EE ,
Domain Driven Design

In the second part of their article, Vasile Buciuman-Coman and Michael Chervenic explore the architecture of Dynamic Business Application after having defined a new Enterprise Framework in Part I.

there is a fundamental difference between architecting software applications and designing other engineered products. Because software works with information, and information is the “carrier” for change, then change has to be built into the system architecture at the most basic level.

The core of the proposed solution is based on two frameworks:

These two frameworks allow us to handle and coordinate changes in business operations and technical team operations effectively and efficiently. For the design process, business operations and technical team operations can be considered two distinct adaptive systems, each with their own requirements.

The authors note that:

...architecting a client-server application capable to run at the enterprise level is orders of magnitude more complex than a desktop application. The main complexity of the server-side application derives from the fact the it must support two adaptive systems, one for the technical team and one for the business team, each with their own operations and controlled hierarchy.

The architecture style of Dynamic Business Applications (dubbed Adaptive Enterprise Operating Platform -AEOP) is focused on productivity for the technical team operations, the business operations and the development team. Increased levels of productivity are reached through an entity lifecycle/event-based architecture style. However,

the EDA (Event Driven Architecture) model found in the literature is different than the AEOP event model. The EDA is built around a stream of unstructured events, while the AEOP is built around a stream of structured events that are linked together by a clear set of lifecycle templates.

After describing in great details the architecture of Dynamic Business Applications, the authors conclude:

AEOP standardizes the architecture for server-side applications, something that is missing from current IT

Technologies and architecture concepts like SOA play a minor role in this architecture. Components like BPM engines, schedulers, messaging have a clear role in this architecture, however they have very little impact on the design.

  • This article is part of a featured topic series on SOA
Interview with Grady Booch and the software's "dirty little secret" by Vasile Coman Posted
Very interesting ideas by Harmen Dijkstra Posted
  1. Back to top

    Interview with Grady Booch and the software's "dirty little secret"

    by Vasile Coman

    Here is an interesting quote from an interview Grady Booch gave to Scientific American about software few days ago (June 17, 2008)

    Software's Dirty Little Secret - An interview with Grady Booch, the Indiana Jones of computer programming
    :




    "Q:You say there's a "dirty little secret" when it comes to writing software. Care to share that with us?"


    "A: <quote> In other disciplines, engineering in particular, there exist treatises on architecture. This is not the current case in software, which has evolved organically over only the past few decades. All software-intensive systems have an architecture, but most of the time it's accidental, not intentional. This has led to the condition of most software programming knowledge being tribal and existing more in the heads of its programmers than in some reference manual or publicly available resource.</quote>"

  2. Back to top

    Very interesting ideas

    by Harmen Dijkstra

    Hi, I've read both papers last weekend and must say that you propose some very interesting concrete approaches to deliver on the contents of the DBA paper by Forrester. I'm eagerly awaiting part three where you promise to describe a practical implementation, as I do have some doubts as to how the containers are implemented technology wise.

    Harmen

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.