Model Driven Architecture

1
Model Driven Architecture

• An Alternative Implementation Approach
• Werner Froidevaux
• wfro_at_omex.ch

2
Generating Implementations
Platform-Independent Model
MDA tool applies a standard mapping to generate
Platform-Specific Model (PSM) from the PIM. Code
is partially automatic, partially hand-written.
XML/SOAPModel
OtherModel
CORBA Model
Java/EJBModel
Map PSM to application interfaces, code, GUI
descriptors, SQL queries, etc.
MDA Tool generates all or most of the
implementation code for deployment technology
selected by the developer.
XML/SOAP
Other
CORBA
Java/EJB
3
Benefit of MDA

• Generators accelerate component development
  typically by orders of magnitude compared to
  manual implementation
• and many more
• BUT

4
B U T

• effective code generation requires UML
  extensions. Vendors have defined proprietary
  dialects of UML, standard dialects are appearing
  (e.g. Web Application Extension (WAE), UML
  Profile for EJB (JCP JSR-26))
• tools generate platform-specific bindings (e.g.
  CORBA-, EJB-, WebServices bindings)

• vendor-specific, non-portable models
• non-interoperable applications

• non-portable application-code

5
MDA The Modeling Babylon?

• NO. MDA already speaks Esperanto

Q How much platform-specific modeling is
required?
A None.
A Very few. Only PIM mappings.
Q How much code generation is required?
6
Joking?

• NO. It already has been shown that
  platform-specific modeling is not really
  required
• Proven in several years of experience with
  extensive use of MOF, UML, XMI in customer
  projects. Started with prototype implementation
  and presentation 'MOF compliant IFR' _at_ 1999 OMG
  Meeting, Philadelphia.
• and other (UML-VM by Dirk Riehle),

7
The MOF IFR Prototype _at_ 1999

• Extensive use of code generators (PIM and PSM)

GUI Generator
Implementation Generator
Rose Exporter
MOF Repository
XML Exporter/ Importer
IDL Generator
Component
MOF Generator Toolset
8
Lessons Learned

• 1 PSMs are not required.
• 2 Let PIM be part of runtime environment.
• 3 Separate client-binding from server-binding.

9
1-1 PSMs are not required

• PIMs are standardized and portable. E.g. MOF, UML
  without extensions.
• PSMs are typically proprietary and non-portable.

The restriction to PIMs requires a
platform-independent concept of a component.
10
1-2 PSMs are not required

• What is a platform-independent component?
• Required
• platform-independent language bindings
• platform-independent component model and
  deployment
• abstraction from the middleware
• Optional
• abstraction from programming language

11
1-3 PSMs are not requiredPlatform-independent
language bindings

• Use a platform-independent metamodel to specify
  components, e.g. MOF. Apply MOF mappings to
  generate platform-independent bindings JMI, XMI,
  JDO, customer-specific, etc. (NOTE MOF is
  level M3 and is used to generate level M2
  bindings. However the mappings can be applied to
  any MOF-compliant model).

Component
Component Implementation
MOF Mapping
MOF-compliant Model
platform-independent binding (e.g. JMI)
12
1-4 PSMs are not requiredPlatform-independent
component model

• Provide a generic, platform-specific runtime
  environment for platform-independent components
  which abstracts from component model and
  middleware.

platform-specific component
1..n
platform-independent component
PI config
EJB, CCM, .NET,
13
1-5 PSMs are not requiredAbstract from the
middleware

• Generic runtime environment for PI components
  must support pluggable middleware.

14
1-6 PSMs are not requiredAbstract from the
programming language

• UML Approach Use UML Action Semantics, Activity
  Diagrams or Sequence Diagrams to model behavior.
  Generate component implementation.
• GPPL Approach General Purpose Programming
  Languages such as Java, C allow to implement
  platform-independent components if
• platform-independent bindings are used
• component model and middleware runtime
  abstraction is used

15
2 Let PIM be part of runtime

• Let the PIM be part of the runtime environment.
  Support reflective and typed programming.
• This allows the implementation of generic,
  model-driven framework and components. (minimize
  use of generators. No generation, implementation
  and testing for each model).

model-driven implementation
Allows to implement components which
implement generic patterns, e.g. state,
role, security, accounting, notification,
logging, persistence, wrappers, bridges.
PIM
reflective binding
EJB
CORBA
16
3 Separate Client-binding from Server-binding

• Separate binding used to access a component and
  binding which is used to implement a component.
• Client is not required to use a specific binding.
  
• Component can be used by different types of
  clients.

PI Component
Implementation
JMI
Generic
PI Component
Implementation
JDO
JDO
17
Expected Benefits

• Portable, reusable models only.
• Portable, platform-independent components.
• Fast, simple and transparent roundtrips through
  minimized use of code generators.
• When is this reality?

18
SPICE An MDA Implementation

• NOW. The OMEX/SPICE application and integration
  framework provides
• generic, model-driven runtime environment for
  platform-independent components
• No platform-specific modeling required
• Library of standard components implementing
  standard patterns
• Proven since years in real-world projects

19
SPICE An MDA Implementation

• Some Facts and Figures
• Code generators lt 5'000 LOCs.
• Average component size 100-2'000 LOCs. Samples
  MOF 500 LOCs Role, State, Persistence 2'000
  LOCs.
• Supports mixed in-process, EJB, CORBA deployment.
• Standard plugins type checking, persistence,
  role, state, ocl,
• Supports MOF, JMI, XMI, JDO,

20
Questions?

• ? ? ?