This addressed better design management, but the inherent problems that were in CORBA did not go away. Although some loose coupling occurred.
2001 – Model Driven Architecture Introduced
Motive was to achieve
a better holistic design,
while promoting better use of strong notation (UML)
better ‘separation of concerns’
Platform Independent Model
Platform Specific Model
model transformation and engineering change management
As software architectures evolved, the designs moved from hardware into software.
Telecom is a classic example. The architecture that was tightly coupled to the hardware gradually moved the management functions embedded in the hardware into the software.
Almost all the embedded engineering is ‘event dependent’ . This means a paradigm shift in the software architecture approach to incorporate the functions migrated from the hardware.
During late 2000s
SOA has taken center seat..
SOA relies on
This means the atomic structure of the ‘services’ is lot more larger than the object oriented ‘function’
Furthermore, the services are brought together to instantiate business processes by another component - ‘orchestration’.
The design of the ‘orchestration’ layer creates a greater need for an architecture that is ‘event driven’ such that this layer is service/function independent.
To achieve a coherent model, the event driven design paradigm requires being shifted from the level of services into the orchestration component of the architecture framework. This requires creating another layer called ‘Enterprise Service Bus’
The ESB concept is a new approach to integration that can provide the underpinnings for a loosely coupled, highly distributed integration network that can scale beyond the limits of a hub-and-spoke EAI broker.
An ESB is a standards-based integration platform that combines
data transformation and
to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity.
Ref: David Chappell
What are Services
Services are request / response mechanisms.
A service consumer makes a request and a service provides a response. Essentially, a service consumer calls the service operation of a service and the information flows through the service interface. Then the service implementation processes the request and provides the information to the service interface that responds.
When Services do not act as requestors but instead Events trigger a complex array of interdependent business processes to respond to a condition, the design paradigm shifts to :
Event Driven Architecture (EDA)
In an EDA, a complex array of business processes turns into a non-hierarchical net-centric structure
While EDA is fundamentally different from SOA, the two styles are not contradictory and, in fact, they work together well.
EDA is a request/response architecture
Service consumers make requests of services and wait for responses
The idea of EDA is "fire and forget." Systems are constructed to respond to events that occur in software or in the real world.
Once an event has occurred, a cascading process begins in reaction to the event.
Ref: Enterprise SOA: Designing IT for Business Innovation By Dan Woods; Thomas Mattern
Field Events Event Sampling & Management Event Processing Event(s)/Response Event Decision Management Event in Space Event in Time
Business Activity Monitoring Sense / Interpret Event in Space Event in Time Interpret & Response Knowledge Management System Event Data Base Rules Engine Event Handler Event Disseminator Event Assimilator Event Controller Sequential Date Aggregator Pattern Logistics Stream Complex Stochastic Discreet Event Modeling Probabilistic Modeling Field Events Event Sampling & Management Event Processing Event/s Response Event Decision Management Event Listener Event Correlation Engine