Model Driven Architecture
An Alternative Implementation
Approach
Werner Froidevaux
[email protected]
1
2002 OMG Meeting, Helsinki
Generating Implementations
PlatformIndependent
Model
CORBA
Model
Java/EJB
Model
XML/SOAP
Model
Other
Model
Map PSM to application
interfaces, code, GUI
descriptors, SQL queries, etc.
CORBA
2
2002 OMG Meeting, Helsinki
Java/EJB
XML/SOAP
Other
MDA tool applies a
standard mapping to
generate PlatformSpecific Model (PSM)
from the PIM. Code is
partially automatic,
partially hand-written.
MDA Tool generates all
or most of the
implementation code
for deployment
technology selected
by the developer.
Benefit of MDA
• Generators accelerate component
development typically by orders of
magnitude compared to manual
implementation
• … and many more
BUT
3
2002 OMG Meeting, Helsinki
BUT…
• 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))
• vendor-specific, non-portable models
• non-interoperable applications
• tools generate platform-specific bindings (e.g.
CORBA-, EJB-, WebServices bindings)
• non-portable application-code
4
2002 OMG Meeting, Helsinki
MDA: The Modeling Babylon?
• NO. MDA already speaks
Esperanto
Q: How much
A: None.
platform-specific
modeling is
required?
Q: How much code
generation is
required?
5
2002 OMG Meeting, Helsinki
A: Very few.
Only PIM
mappings.
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' @ 1999
OMG Meeting, Philadelphia.
– … and other (UML-VM by Dirk Riehle), …
6
2002 OMG Meeting, Helsinki
The MOF IFR Prototype @ 1999
• Extensive use of code generators (PIM and
PSM)
M2 Level Server
GUI
Generator
PackageFactory
Interface
PackageFactory
CORBA Objects
Persistency Store
package
instance
Package
Interface
MOF
Repository
XML
Exporter/
Importer
Class Level
Interface
Class Level
CORBA Objects
Instance Level
Interface
Instance Level
CORBA Objects
Association Level
Interface
Persistency Layer
Rose
Exporter
Implementation
Generator
Package
CORBA Objects
class
singleton
instance
association
instance
ab
ab
ab
ab
Assocation
CORBA Objects
POA
IDL
Generator
MOF Generator Toolset
7
2002 OMG Meeting, Helsinki
activate_object()
deactivate_object()
Component
class
singleton
instance
association
instance
ab
ab
ab
ab
Lessons Learned
• #1: PSMs are not required.
• #2: Let PIM be part of runtime environment.
• #3: Separate client-binding from serverbinding.
8
2002 OMG Meeting, Helsinki
#1-1: PSMs are not required
• PIMs are standardized
Computation
Independent Model
<<refine>>
<<refine>>
Platform
Independent Model
<<refine>>
J2EE Model
<<refine>>
WebSphere 4 Model
and portable. E.g.
MOF, UML without
extensions.
Platform
Independent Model
<<refine>>
.NET Model
<<refine>>
Windows XP Model
<<refine>>
J2EE Model
<<refine>>
Orbix E2A J2EE
Model
<<refine>>
CORBA Model
<<refine>>
Orbix E2A CORBA
Model
• PSMs are typically
proprietary and nonportable.
The restriction to PIMs requires a platformindependent concept of a component.
9
2002 OMG Meeting, Helsinki
#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
10
2002 OMG Meeting, Helsinki
#1-3: PSMs are not required
Platform-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
MOF-compliant
Model
MOF
Mapping
Component
Implementation
platform-independent
binding (e.g. JMI)
11
2002 OMG Meeting, Helsinki
#1-4: PSMs are not required
Platform-independent component model
• Provide a generic, platform-specific runtime
environment for platform-independent components
which abstracts from component model and
middleware.
PI Component
platform-specific
component
Implementation
PI Component
PI binding
Implementation
PI Component
PI binding
1..n
platform-independent
component
Implementation
PI binding
EJB, CCM, .NET, …
12
2002 OMG Meeting, Helsinki
PI
config
#1-5: PSMs are not required
Abstract from the middleware
• Generic runtime environment for PI components
must support pluggable middleware.
CORBA
EJB
CORBA
EJB
13
2002 OMG Meeting, Helsinki
#1-6: PSMs are not required
Abstract 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
14
2002 OMG Meeting, Helsinki
#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, modeldriven framework and components.
(minimize use of generators. No generation, implementation and testing for each model).
model-driven
implementation
PIM
reflective binding
EJB
15
2002 OMG Meeting, Helsinki
CORBA
Allows to implement
components which implement
generic patterns, e.g. state, role,
security, accounting, notification,
logging, persistence, wrappers,
bridges.
#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
PI Component
Generic
Implementation
PI Component
JMI
Implementation JDO
JDO
16
2002 OMG Meeting, Helsinki
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?
17
2002 OMG Meeting, Helsinki
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
18
2002 OMG Meeting, Helsinki
SPICE: An MDA Implementation
• Some Facts and Figures:
– Code generators < 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, …
19
2002 OMG Meeting, Helsinki
Questions?
???
20
2002 OMG Meeting, Helsinki
Descargar

MDA: An Alternative Implementation Approach