1 / 12

Service Oriented and Model Driven Architectures

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

ike
Download Presentation

Service Oriented and Model Driven Architectures

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. T-86.5165 - Seminar on Enterprise Information Systems (2007): Service-Oriented Architecture and Software Engineering Service Oriented and Model Driven Architectures Pankaj SaharanCarlos Martinez 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. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion 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. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion 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 1. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion CIM PIM PSM Code 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. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion T-86.5165 Service-Oriented Architecture and Software Engineering

  6. MDA and… SOA. Unifying … Requirements Models: … Service Models: … Architectural Models: 1. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion Project Data Technical New/Existing Business Computation Independent Model Computation Independent Model Computation Independent Model Business Process Business Rules… Business Process Business Rules… Use Cases Abstract Class Model… Interaction Model PIM Service Interface Abstract Class Model Interaction Model… Platform Independent Model Platform Independent Model Platform Independent Model Technical Requirements Technical Patterns Interface Definitions Process-ServiceDependency Corporate Data Model PSM Service Interface Design Class Model Interaction Model… Platform Specific Model Platform Specific Model Platform Specific Model Base Classes Utilities Technical Services Physical Data Model Implementation Code Implementation Code Implementation Code Service Code Dependee Service References Class Libraries Database Definition 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. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion T-86.5165 Service-Oriented Architecture and Software Engineering

  8. 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 Similarities and Differences 1. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion 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. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion 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. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion 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. Introduction2. SOA 3. MDA 4. Combining SOA and MDA5. Conclusion T-86.5165 Service-Oriented Architecture and Software Engineering

  12. Thank you for your attention questions ? T-86.5165 Service-Oriented Architecture and Software Engineering

More Related