1 / 20

Model Driven Architecture

Model Driven Architecture. An Alternative Implementation Approach Werner Froidevaux wfro@omex.ch. Generating Implementations. Platform- Independent Model.

rayya
Download Presentation

Model Driven Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Model Driven Architecture An Alternative Implementation Approach Werner Froidevaux wfro@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. OtherModel XML/SOAPModel Java/EJBModel CORBA Model 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. Other XML/SOAP Java/EJB CORBA

  3. Benefit of MDA • Generators accelerate component development typically by orders of magnitude compared to manual implementation • … and many more BUT

  4. 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) B U T … • 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' @ 1999 OMG Meeting, Philadelphia. • … and other (UML-VM by Dirk Riehle), …

  7. M2 Level Server Persistency Layer PackageFactory Interface PackageFactory CORBA Objects Persistency Store package instance Package Interface Package CORBA Objects class singleton class singleton Class Level Interface Class Level CORBA Objects instance instance Instance Level Interface Instance Level CORBA Objects association instance association instance a  b a  b a  b a  b a  b a  b a  b a  b Association Level Interface Assocation CORBA Objects POA activate_object() deactivate_object() The MOF IFR Prototype @ 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. PIMs are standardized and portable. E.g. MOF, UML without extensions. PSMs are typically proprietary and non-portable. #1-1: PSMs are not required 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. PI Component PI Component PI Component Implementation Implementation Implementation PI binding PI binding PI binding #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. CORBA EJB CORBA EJB #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. PI Component Implementation JMI #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 < 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? ? ? ?

More Related