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

2. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 2 Introduction In this study we analyze the relationships between Service-Oriented Architectures (SOA) and Model Driven Architectures (MDA). 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. 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

3. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 3 SOA 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 inter-dependencies. 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. 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

4. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 4 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 before deployment CIM PIM PSM Code 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

5. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 5 MDA Standards 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. 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

6. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 6 MDA and… Computation Independent Model Platform Independent Model Platform Specific Model Implementation Code Business Business Process Business Rules… Corporate Data Model Physical Data Model Database Definition Technical Technical Requirements Technical Patterns Interface Definitions Base Classes Utilities Technical Services Class Libraries Data Process-Service Dependency … Architectural Models:… Requirements Models: Project Business Process Business Rules… Use Cases Abstract Class Model… Interaction Model Computation Independent Model Platform Independent Model Platform Specific Model Implementation Code … Service Models: New/Existing PIM Service Interface Abstract Class Model Interaction Model… PSM Service Interface Design Class Model Interaction Model… Service Code Dependee Service References Computation Independent Model Platform Independent Model Platform Specific Model Implementation Code SOA. Unifying «Architecture» (Business/Data) «Architecture» (Technical) «Requirements»«Service» CIM Business Process Model Requirements Glossary Business Process Model Requirements Glossary PIM Corporate Data Model Technical Requirements Technical Patterns Interface Definitions Use Cases Information Model Service Interface Information Model Component Architecture Interaction Diagrams State Diagrams PSM Physical Corporate Data Model Base Classes Utilities Technical Services Well Formed Classes Applied Patterns Code Database DefinitionClass Libraries Synchronized Code Component Implementation Schema, Meta-data 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

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

8. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 8 Similarities and Differences 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. MDA-enabled tools follow OMG-standardized 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 registry that contains pointers, not actual data. Whereas repository in MDA works as unified data store for model artefacts of differing metamodels 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

9. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 9 Problems 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 starting point, they will find that they have the solution to achieving business agility through SOA. 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

10. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 10 MDA-SOA: Current and future 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 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

11. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 11 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 “meta-bus”  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 to the SOA Kingdom! 1. Introduction 2. SOA 3. MDA 4. Combining SOA and MDA 5. Conclusion

12. Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 12 Thank you for your attention questions ?