SOA - Service Oriented Architecture MDA - Model Driven Architecture

1. T-86.5165 - Seminar on Enterprise Information Systems (2007):
Service-Oriented Architecture and Software Engineering
Agenda
ervice Oriented and Model Driven
Architectures
Pankaj Saharan
Carlos Martinez

2. Introduction
Agenda
In this study we analyze the relationships
between
Service-Oriented
Architectures
(SOA) and Model Driven Architectures (MDA).
1. Introduction
2. SOA
3. MDA
4. Combining
SOA and MDA
5. Conclusion
The purpose of this paper is to find the
benefits
when
combining
these
architectures. First they are analyzed in
depth the architectures, to be able to find
the
similarities,
differences,
how
to
combine and problems.
The practical benefits of SOA are widely
recognized, relatively easy to describe, but
more challenging to implement.
Using a model-driven approach, enterprises
can
define
business
models
without
consideration for the underlying technical
implementations.

3. SOA
Agenda
1. Introduction
2. SOA
3. MDA
4. Combining
SOA and MDA
5. Conclusion
SOA in context of:
Business: SOA is a set of services that a business wants
to expose to their customers and partners, or other
portions of the organization.
Architecture: It is an architectural style which requires a
service provider, requestor and a service description. It
consists of a set of architectural principles, patterns and
criteria which address characteristics such as modularity,
encapsulation, loose coupling, separation of concerns,
reuse, composability and single implementation.
Technology/Application Development: a
programming model complete with standards, tools and
technologies
Characteristics of SOA
The software components in a SOA are services based on
standard protocols.
Services in SOA have minimum amount of interdependencies.
SOA uses granularity to provide effective composition,
encapsulation and management of services.
SOA offers coarse-grained business services, as opposed to
fine-grained software-oriented function calls.
Its communication infrastructure is designed to be
independent of the underlying protocol layer.

4. MDA
Agenda
1. Introduction
2. SOA
3. MDA
4. Combining
SOA and MDA
To bridge the gap that exists between an
organization’s lines of business and IT’s
understanding of the business drivers
To separate design from architecture and
realization technologies
Provides the added assurance that best
practices are well documented and
communicated throughout the organization
CIM
before deployment
PIM
PSM
5. Conclusion
Code

5. MDA Standards
Agenda
1. Introduction
2. SOA
3. MDA
4. Combining
SOA and MDA
5. Conclusion
Unified Modeling Language (UML): For describing the
problem domain and the solution architecture
Meta Object Facility (MOF): For describing and manipulating
models and metadata, general purpose modeling languages or
domain specific modeling languages (metamodels)
XML Model Interchange (XMI): For exchanging model &
metadata information in XML format and generating XSD
Common Warehouse Model (CWM): For describing data
mappings and database schemas
Reusable Asset Specification (RAS): Packaging,
distributing and reusing software asset metadata
Thus, Model Driven Architecture is central to a plan to
address the requirements for a high degree of
flexibility while reducing cost and risk .
The combined leverage of early and incremental
implementation combined with automated and
repeatable testability provides a profound and
lasting benefit to the effectiveness of the entire
system for its entire lifetime.

6. MDA and… SOA. Unifying
Agenda
…«Architecture»Models:
Service
Requirements Models:
Architectural Models:
«Architecture»
(Business/Data)
CIM
3. MDA
4. Combining
SOA and MDA
Busines s Proces s
Model
Requirements
Glo ss ar y
Computation
Independent
Model
Platform rate Data
Corpo
PIM
Model
Independent
Model
Platform
Specific
Modelysic al Cor porate
Ph
PSM
Data Mo de l
5. Conclusion
«Requirements»
Business
1. Introduction
2. SOA
(Technical)
Implementation
Code
Cod
Database De finit ion
e
Project
Technical
New/Existing
Busi ne ss Proces s
Model
Requirements
Glo ss ar y
Business Process
Business Rules…
T ec hnical
Re qu irements
T echnic al Patte rns
I nterface
D efinit ions
Data
Business Process
Business Rules…
S ervic e I nterface
Information Mo
Use Cases
PIM Service Interface del
Technical Requirements Archi tectur e
Component
Abstract Class Model…
Corporate
Technical Patterns eract ion D iagrams
Abstract Class Model
I nt
S tate Dia gr ams
Interface Definitions
Interaction Model Data Model
Interaction Model…
U se Cas es
I nfor ma tion Model
Process-Service
Dependency
Bas e Class es
U til ities
T echnic al Servic es
«Service»
PSM Service
Base Classes Interface
Design Class ModelPhysical
Utilities
Data Model
Technical Services ll F or med Class es
Interaction Model…
We
Appl ied Patt erns
Service Code
Database
S
Dependee Serviceynchr oniz ed Code on
References
Component I mplementati
Definition
Class Libraries
Class Librar ies
Sche ma, Meta-data

7. Key Benefits
Agenda
1. Introduction
Improved Productivity for Architects, Designers,
Developers and Administrators
Lower cost of Application Development and
Management
2. SOA
Enhanced Portability and Interoperability
3. MDA
4. Combining
SOA and MDA
5. Conclusion
Business Models and Technologies evolve at
their own pace on platform(s) of choice
Automation is the key factor

8. Similarities and Differences
Agenda
1. Introduction
2. SOA
3. MDA
4. Combining
SOA and MDA
5. Conclusion
Both aim to minimize the gap
between the higher level
business management and IT
department in the
organization.
MDA applications interoperate
and are reusable: The MDA,
designed from the start to
implement in multiple
middleware platforms, codes
cross-platform invocations
where needed, not only within
a given application, but also
from one to another
regardless of the target
platform assigned to each.
This is in line with the fact the
services in SOA are reusable
and interoperable.
Metadata is the foundation of
both SOA and MDA.
SOA promises business agility
through user configuration
and orchestration of services.
But MDA is automated and
does not need manual
configuration process. MDAenabled tools follow OMGstandardized pathways to
automate the transformation
from your designers' business
model into your
implementation, producing
new applications faster,
better and cheaper.
SOA defines an architectural
paradigm for how you use
interconnected systems at a
macro level, it says nothing
about the tooling you use to
go from high level
architecture to working code.
In contrast, MDA allows you to
follow any type of
architectural paradigm, but
provides a well-defined
approach to go from high level
to code
MDA uses Ontology while it is
good for SOA.
SOA concepts include a

9. Problems
Agenda
1. Introduction
2. SOA
3. MDA
4. Combining
SOA and MDA
5. Conclusion
It is difficult to specify the requirements, domain and application
models in the first place.
The notion of a "platform" in MDA is rather complex and highly
context dependent. For example, in some situations the platform
may be the operating system and associated utilities; in some
situations it may be a technology infrastructure represented by a
well-defined programming model such as J2EE or .Net; in other
situations it is a particular instance of a hardware topology.
Generally the designers get distracted with defining the "platform"
instead it should be focused on what models at different levels of
abstraction are used and for what different purposes.
Model transformation and refinement: By thinking of software and
system development as a set of model refinements, the
transformations between models become first class elements of the
development process. A great deal of work takes places in defining
these transformations, often requiring specialized knowledge of the
business domain and the technologies being used for
implementation.
MDA requires intelligent, highly trained architects, and also
specialist technology. Good architects are hard to come by, and
specialist technology can be expensive.
MDA is not widely used in IT enterprises today and SOA has also just
flourished without showing up its full ROI. Hence the enterprises
would not take chance knowing and implementing the combination
of the technologies without strong motivation.
Currently, enterprises implementing SOA often identify semantic
interoperability as a problem. Perhaps, if they make semantics their

10. MDA-SOA: Current and future
Agenda
1. Introduction
2. SOA
3. MDA
4. Combining
SOA and MDA
5. Conclusion
Modeling approach (Service Oriented Modeling)
SOA Framework mapped to MDA, otherOMG stds.
SOA Metamodel
Focus on complete Life Cycle of a Service
–Model, develop, manage and monitor
–Metrics (service availability, performance, maturity,
SLA…)
Mapping of Services to business
functions/processes and components
SOA Governance –Policy, Contract, Regulatory
Compliance
Standard Service Registry Repository model
Gap between service development and service registration
and deployment
Correlation/mapping to EDA
Events that trigger Service execution
Causality relation with Events
-Sense and respond
Service Semantics (Service Ontologies)
Way to model web service functionality and policy
independent of WS* platform languages

11. Conclusion
Agenda
1. Introduction
2. SOA
3. MDA
4. Combining
SOA and MDA
5. Conclusion
Combining SOA with MDA can bring many unique
benefits
Metadata Modeling
 UDDI
Ineffective metadata categorization
No broad adoption – IBM, Microsoft, SAP gave up
support
 Semantic Web
Ontology based
MDA uses ontology
Ontology good for SOA
Achieve Business Agility through Model-Driven SOA
 MDA metadata tools manage SOA service model “metabus”
 MOF (MDA’s heart) transforms from PIM to PSM
Many ontology tools, e.g. Protégé, Visio, etc
Code generation
SOA, BPM and Model-driven Development: The Keys

12. Agenda
Thank you for your attention
questions ?