Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 1 Service...

23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering

1

AgendaAgenda

Service Oriented and Model Driven Architectures

Service Oriented and Model Driven Architectures

Pankaj SaharanCarlos Martinez

T-86.5165 - Seminar on Enterprise Information Systems (2007):Service-Oriented Architecture and Software Engineering


2

AgendaAgenda

IntroductionIntroduction

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

AgendaAgenda

SOASOASOA 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 SOAThe 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


5. Conclusion


4

AgendaAgenda

MDAMDA

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


5. Conclusion


5

AgendaAgenda

MDA StandardsMDA StandardsUnified Modeling Language (UML): For describing the problem domain and the solution architectureMeta 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 XSDCommon Warehouse Model (CWM): For describing data mappings and database schemasReusable 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


5. Conclusion


6

AgendaAgenda

MDA and…MDA and…

ComputationIndependentModel

PlatformIndependentModel

PlatformSpecificModel

ImplementationCode

Business

Business ProcessBusiness Rules…

Corporate Data Model

Physical Data Model

Database Definition

Technical

Technical RequirementsTechnical Patterns

Interface Definitions

Base ClassesUtilities

Technical Services

Class Libraries

Data

Process-ServiceDependency

… Architectural Models:… Requirements Models:

Project

Business ProcessBusiness Rules…

Use CasesAbstract Class Model…

Interaction Model




ImplementationCode

… Service Models:

New/Existing

PIM Service InterfaceAbstract Class ModelInteraction Model…

PSM Service InterfaceDesign Class ModelInteraction Model…

Service CodeDependee Service References




ImplementationCode

SOA. Unifying

«Architecture»(Business/Data)

«Architecture»(Technical)

«Requirements» «Service»

CIM

Business Process Model

RequirementsGlossary

Business Process Model

Requirements Glossary

PIM Corporate Data Model

Technical Requirements

Technical PatternsInterface

Definitions

Use CasesInformation Model

Service InterfaceInformation Model

Component ArchitectureInteraction Diagrams

State Diagrams

PSM Physical Corporate Data Model

Base ClassesUtilities

Technical Services

Well Formed ClassesApplied Patterns

Code

Database Definition Class LibrariesSynchronized Code

Component ImplementationSchema, Meta-data

1. Introduction

2. SOA

3. MDA


5. Conclusion


7

AgendaAgenda

Key BenefitsKey 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


5. Conclusion


8

AgendaAgenda

Similarities and DifferencesSimilarities and DifferencesBoth 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 codeMDA 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


5. Conclusion


9

AgendaAgenda

ProblemsProblemsIt 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


5. Conclusion


10

AgendaAgenda

MDA-SOA: Current and futureMDA-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 componentsSOA Governance–Policy, Contract, Regulatory ComplianceStandard Service Registry Repository model

Gap between service development and service registration and deployment

Correlation/mapping to EDAEvents that trigger Service executionCausality relation with Events

-Sense and respondService Semantics (Service Ontologies)Way to model web service functionality and policy independent of WS* platform languages

1. Introduction

2. SOA

3. MDA


5. Conclusion


11

AgendaAgenda

ConclusionConclusion

Combining SOA with MDA can bring many unique benefits Metadata Modeling UDDI

Ineffective metadata categorizationNo broad adoption – IBM, Microsoft, SAP gave up

support Semantic Web

Ontology basedMDA uses ontologyOntology 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


5. Conclusion


12

AgendaAgenda

Thank you for your attentionThank you for your attention

questions ?questions ?

Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 1 Service...

Documents

Transcript of Agenda 23 April, 2007 T-86.5165 Service-Oriented Architecture and Software Engineering 1 Service...