OMG Meeting, Helsinki Model Driven Architecture An Alternative Implementation Approach Werner Froidevaux

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

OMG Meeting, Helsinki Benefit of MDA Generators accelerate component development typically by orders of magnitude compared to manual implementation … and many more BUT

OMG Meeting, Helsinki 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

OMG Meeting, Helsinki MDA: The Modeling Babylon? NO. MDA already speaks Esperanto Q: How much platform-specific modeling is required? A: None. Q: How much code generation is required? A: Very few. Only PIM mappings.

OMG Meeting, Helsinki 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 1999 OMG Meeting, Philadelphia. –… and other (UML-VM by Dirk Riehle), …

OMG Meeting, Helsinki The MOF IFR 1999 Extensive use of code generators (PIM and PSM) MOF Generator Toolset Persistency Layer Persistency Store package instance class singleton class singleton instance M2 Level Server Instance Level CORBA Objects Class Level CORBA Objects Package CORBA Objects PackageFactory CORBA Objects POA activate_object() deactivate_object() Assocation CORBA Objects association instance a  b association instance a  b PackageFactory Interface Package Interface Class Level Interface Instance Level Interface Association Level Interface MOF Repository Rose Exporter IDL Generator XML Exporter/ Importer Implementation Generator GUI Generator Component

OMG Meeting, Helsinki Lessons Learned #1: PSMs are not required. #2: Let PIM be part of runtime environment. #3: Separate client-binding from server- binding.

OMG Meeting, Helsinki #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.

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

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). MOF-compliant Model MOF Mapping Component Implementation platform-independent binding (e.g. JMI) Component

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. Implementation PI binding PI Component Implementation PI binding PI Component Implementation PI binding PI Component platform-specific component platform-independent component 1..n EJB, CCM,.NET, … PI config

OMG Meeting, Helsinki #1-5: PSMs are not required Abstract from the middleware Generic runtime environment for PI components must support pluggable middleware. EJBCORBA EJB CORBA

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

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, model- driven framework and components. (minimize use of generators. No generation, implementation and testing for each model). Allows to implement components which implement generic patterns, e.g. state, role, security, accounting, notification, logging, persistence, wrappers, bridges. model-driven implementation reflective binding EJBCORBA PIM

OMG Meeting, Helsinki #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. Implementation JMI PI Component Implementation JDO PI Component Implementation Generic PI Component JMI JDO

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?

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

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, …

OMG Meeting, Helsinki Questions? ? ? ?