SlideShare a Scribd company logo
1 of 29
Book Author: Nicolai M. Josuttis
    Chapter Eighteen: Model-Driven Service Development




IT-Slideshares                      http://it-slideshares.blogspot.com/
18.0 Introduction to MDSD
 Service interfaces in heterogeneous environments require a
  lot of code.
 Most of this code often has the same structure, differing
  only according to the different parameters, exceptions, and
  other configuration data.
 This is a perfect situation for the application of code
  generators, or, to use a term that is more hype, model-
  driven service development (MDSD).
 Model-driven service development encompasses code both
  for the provider and for the consumers.
18.1 Generated Service Code
 Because SOA is a concept for heterogeneous environments, you might need a lot of different
   code to implement and call a service.
       The structure of the code is usually pretty much the same for any given platform.
       Code for two different services will differ only in the specific data transferred , including aspects such as
        message exchange pattern.
 The code that deals with this data conceptually will be pretty much the same.
       You could use libraries and frameworks to deal with the commonalities but it has some drawback 
        should generate such code based on a service description.
 Code generated for a service might include (but is not limited to):
       Code that provides the framework for implementation details of the service.
       Code that provides the ability to call a service.
       Code that allows you to deal with the service inside the infrastructure,
       Code that provides a framework for tests.
       Documentation, which is strictly not code but a result of a generator working on a service description.
        Scripts for the processing of generated artifacts during build and deployment.




       Figure 18.1 demonstrates a possible MDSD approach.
18.2 Modeling Services
 The idea of generating code is pretty old.
 Following the rule “Three Strikes and You Automate”
  this is a common mechanism to avoid doing the same
  work again and again.
 However, to be a bit more concrete, let’s dig deeper
  into the general concepts of code generation and
  model-driven software development for services.
18.2.1 Terminology
   If you compare two hard-coded implementations of a service (or of a service call), you can identify
    three types of code:
        Generic code that is the same for each implementation.
        Schematic code that has the same structure but varies somewhat according to the concrete situation.
        Code that has no commonalities.
   Frequently, the same task can be performed using either generic code or schematic code.
   The following example highlights the difference between the implementations.
        With a generic approach
          logName(service.getName( ));
          for (int i=0; i<service.getParams( ).getSize( ); ++i) {
                               Param param = service.getParam(i);
                               logParam (param.getName(), param.getValue( ).asString( ));
          }


        With a schematic approach.
          logName("getContractData");
          logParam ("contractId", contractId.asString( ));
          logParam ("firstName", firstName);
          logParam ("lastName", lastName);
          logParam ("isActive", isActive ? "true" : "false");
          ...

   Both forms have pros and cons.
        Which solution is preferable depends on the exact circumstances; there is no hardand- fast rule.
18.2.1 Terminology (Cont)
 Generic code can usually be part of a framework because it does not have to
  change for every service instance.
 In contrast, schematic code is specific to a service instance and has to be
  generated from a formal description of the service (defining the service
  name, parameter names, and parameter types).
 The format of the source can vary; for example, it can be a UML class (see
  Figure 18-2) or an XML file (see Figure 18-3).




 Regardless of its format, such a source is called a model (because it abstracts
  implementation details).
18.2.1 Terminology (Cont)
   Beside of its format , a model usually has a specific structure.
        The structure of a model is called a meta model.
        In other words , a metal model defines the formal structure and element of a model.
        A metal model for the preceding figures might look like figure 18.4




   As you have seen, there are very different ways to formulate a model.
   The concrete notation used to specify a model is called a modeling language or domain-specific
    language(DSL)
   The code generated out of a source (model) is usually called a generation , and you can transform
    one model into another model , which is usually called a transformation.
   Some model-driven approaches distinguish between platform-independent models (PIMs) and
    platform-specific models (PSMs)
        In practice , it’s difficult to make a black-and-white distinction between PIMs and PSMs , because models are
         usually specific to some platform aspects while independent from other platform aspects.
   Note also that transformations are not necessarily bidirectional.
        MDSD usually is not able to perform round-trip processing.
18.2.2 The Model-Driven Tool Chain
 The notation (DSL) that you use for your models will impact your choice of tools, because there
   are specific tools that allow you to operate directly on the abstraction layer of specific
   notations.
       For example,
           For WSDL there are special tools that allow you to create WSDL files using special (even graphical) IDEs.
           Drawback is hard to read and maintain.
           Advantage ,that the tools will assist you in keeping the resulting model well formed.
 In general, for services very different tools and views can be appropriate.
       Note : it is usually not appropriate for defining signatures  A model should not depend on one
        specific tool.
       Ideally there is freedom of choice, and developers can use their favorite text editors, spreadsheet
        tools, UML tools, XML editors, and IDEs. This contributes to acceptance and development performance.
 The usual rules for source code regarding configuration management apply:
       The tools should have very short startup periods so that users can use them to perform small
        modifications quickly.
       The tool should have an appropriate human-machine interface (HMI), so that a minimal number of
        actions (clicks, text input, etc.) are required from the user to get the desired behavior.
       The models must be versionable so that you can maintain and distinguish between different versions
        under development or in production.
       The models should support team development,
 Ideally, models should have a notation that allows you to edit them with an ordinary text editor.
    All configuration-management tools can then work with the models and even perform
   merges or comparisons.
18.3 Meta Models in Practice
   In practice, it is a good idea to define an initial meta model pretty early on.
   This meta model should define the different abilities and properties of specified services in your
    concrete SOA.
   A very trivial meta model was shown in Figure 18-4. More practical meta models might, in
    addition, do the following:
        Provide the ability to group services and service operations.
        Define a type system that defines fundamental data types and the way they can be composed (for structures and
         lists).
        Provide all information required to manage services (e.g., specifying providers and
         consumers, contracts, SLAs, and so on).
        Distinguish between abstractions and instances of certain kinds of information.
   Let’s look at a few (still simplified) examples of what a SOA meta model might look like in practice.
   Figure 18-5 mainly deals with the type system.
18.3 Meta Models in Practice (Cont)
   A meta model that represents the relationship between services and systems. (Figure 18-6)




   To deal with an initial meta model, you don’t need very sophisticated tools. (Figure 18.7)




   If you later introduce different types of service specifications, you only have to provide a way to
    transfer these specifications into your model notation. (Figure 18.8)
18.4 Setting Up MDSD Processes
18.4.1 Consumer-Driven Transformations
   Consumer-driven transformations (where those who need the result of a transformation perform it)
    are usually the easiest to establish as companywide policies.
        The consumers only need access to the source (model) and the generator(s).
        An added benefit is that the consumers have the understanding and the infrastructure to verify the generated
         result.
   However, this approach has some limitations:
        The consumer has to know when a new transformation is necessary.
        There might be a security requirement that a consumer should not see the source model.
        If the transformation is complicated (includes manual steps) or takes a long time, each consumer may have to
         invest the same significant effort.




   Figure 18-9 demonstrates an example of a consumer-driven transformation.
18.4.2 Provider-Driven Transformations
 Provider-driven transformations (where those who define the source of a transformation
  perform it) solve the problem of multiple transformations for each consumer.
 However, they also have some drawbacks:
      Verification of the generated code is difficult (if not impossible).
     Unnecessary transformations might happen.
     If the generators are modified, the provider has to know that a new transformation is necessary.
     If the service interface changes, the consumers have to perform corresponding fixes to avoid
      breaking the next build.




 Figure 18-10 demonstrates what the example in Figure 18-9 would look like if the
  transformations were provider-driven.
18.4.3 Third-Party-Driven Transformations
 Third-party-driven transformations (where a separate team performs the
  transformations) are often appropriate when there is a build team that
  integrates source code from different departments as part of an iterative
  software development process.
 The nightly builds might include the necessary code generations.
 The advantage of this approach :
    Both source model and generator modifications result in new corresponding code.
    In addition, the build team should be able to verify the result.
 Some drawbacks of this approach :
    Consuming systems have to be integrated into the general build process.
    If the service interface changes, the consumers have to perform corresponding fixes
     to avoid breaking the next build.
    Setting up nightly builds requires effort and time (although this task probably needs
     to be performed regardless of whether or not you’re using this transformation
     strategy).
18.4.4 MDSD Processes in Practice
 In practice, MDSD processes usually involve a mixture
  of all these approaches.
 There is no perfect transformation policy.
 Instead, you have to decide on a case-by-case basis on
  the corresponding policy to set up the necessary
  processes.
 Transformation processes might even be split into two
  different steps, so that, for example, a service provider
  generates an intermediate WSDL file that the
  consumer then uses to generate its platform-specific
  code.
18.4.5 Labeling
 Scenario :
    In large teams, you need configuration-management support so that you can deal
      with different versions of the same models and generated artifacts
          You have to be able to identify all the different artifacts (models, generated code, hand-written
          code deployment information, and so on) that belong together.
 What are you need ?:
    You need a very clear way to identify which transformation result (code or model)
      belongs to which transformation source (model).  What ?
 Consequence :
    You should be able to identify all the related artifacts with one label or a set of
     corresponding labels.
    Note that in practice labeling should also include the result of a transformation.
    Alternatively, instead of labeling the results, you might label the generators to
     provide traceability for all artifacts.
18.4.6 Debugging
 It is key that the generated code is well formed and readable.
    This includes generating comments that explain what’s happening.
    Without them, only the implementer of the generator will be able to debug
      the generated code.
 Far too often, concrete code-generation policies are exactly the opposite
  of what is useful
    Generators create very condensed code
    Using no empty lines or comments because readability is not considered to
      be an issue
 But even people who implement generators make mistakes, and it’s
  important to be able to follow the data flow of all software.
 The only excuse for not having well-structured generated code is when
  the debuggers operate on the same abstraction layer as the modeling
  language. (Example with BPEL engines and BPEL IDE)
18.4.7 Manually Modified Generated Code
 Sometimes it is necessary to modify generated code by hand.
        Example : A skeleton file will contain both generated and manually created code.
 Initially, this is not a problem.
        Typically you generate skeleton code only once  no risk.
        When the generated code has to be changed due to a modification of the source model  You have to
         regenerate the skeleton code.
 There are many approaches to deal with this problem:
        Use different files
                Code provided for modification is physically separated from code that is completely generated.
        Use protected areas
                Inside the generated code, you mark the beginning and end of each protected area, indicating where manual
                 modifications are allowed
             public void changeAddress (Address newAddress) {
                               //==> Begin Protected Area CustomerService.changeAddress

                              //==> End Protected Area CustomerService.changeAddress
             }

      Generate once
                A third approach is to avoid regenerating the skeleton code.
      Merge generated and manual code
                Tries to merge modifications of the skeleton code with manual extensions using a configuration-
                 management tool’s merge tool.
 None of these approaches is perfect, and you’ll have to figure out which one is best
   for your particular situation.
18.4.8 The Code-Generation Granularity
Dilemma
 Because services should be self-contained, it is usually a good idea to have separate files for
  each service.
 In addition, it might help when the artifacts generated from these files are separated
  accordingly. This helps to isolate necessary generations when source files change.
 In addition, you might want to separate:
       Code for different platforms
       Skeleton from stub code
       Declarations and interfaces from implementations
 Following this advice :
    Skeleton, stub, and test code is created for each platform, as well as a dummy implementation
      plus common interface files for some of these files.
    A file is created for each data type used in the service.
    Build files (such as makefiles) are generated.
    Additional files may be created for the C++ platform, because the code is separated into header
      and definition files.
 Some drawbacks of this approach :
    It’s hard to understand the code organization
    A lot of files must be processed when creating, deploying, and running code.
 Finding the right granularity is not easy.
    What helps is a good organization of the code, so that your directory structure matches your
      process structure.
    This is one reason to separate the sources and results of transformations into different
      directories.
18.4.9 Deployment and Robustness
 Usually, you can’t guarantee that all service participants (providers and consumers) will
  deploy modifications at the same time.
 Each system may have its own (model-driven) software development process, so it may
  take varying amounts of time for modifications to be made (see Figure 18-11).


 This consideration has two important
consequences:
 An enterprise service bus, at least in a
test environment, must be able to deal
with inconsistencies.
 It is almost impossible to make
backward-incompatible modifications
that impact all services.
18.5 Tools
 Because nowadays, almost every modeling language
  uses XML-based formats, one tool for transformations
  and/or code generations might be obvious: eXtensible
  Stylesheet Language Transformations, or XSLT.
 XSLT, however, has some limitations, which In this
  chapter will discuss more. This chapter’ll then present
  an alternative.
18.5.1 XSLT
 An XSLT processor transforms one or more XML files into one or more result
  files, which might be in XML or any other text form.
 The transformations are defined by one or more XSLT stylesheet files.
 These files provide templates for the resulting code, spiced with control
  structures to iterate over input tokens and placeholders to fill in certain data
  derived from the source files (see Figure 18-12).
18.5.1 XSLT (cont)
 For example, say you had the following service description:
 <service name="getContractData">
            <param mode="in">
                     <name>contractId</name>
                     <type>long</type>
            </param>
            <param mode="out">
                     <name>firstName</name>
                     <type>string</type>
            </param>
            <param mode="out">
                     <name>lastName</name>
                     <type>string</type>
            </param>
            <param mode="out">
                     <name>isActive</name>
                     <type>boolean</type>
            </param>
 </service>
18.5.1 XSLT (cont)
 A transformation according to the following stylesheet:
 <?xml version="1.0" encoding="UTF-8"?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

 <xsl:template match="/service">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head> <title><xsl:value-of select="@name"/>( )</title> </head>
   <body>
                <h1>Service: <xsl:value-of select="@name"/>( )</h1>
                Parameters (sorted):
                <table border="1">
                   <tr><td><b>Name</b></td><td><b>Type</b></td>
                                  <td><b>Mode</b></td></tr>
                   <xsl:apply-templates select="param">
                     <xsl:sort select="name" />
                   </xsl:apply-templates>
                </table>
   </body>
   </html>
 </xsl:template>

 <xsl:template match="param">
   <tr><td><xsl:value-of select="name"/></td>
                 <td><xsl:value-of select="type"/></td
                 <td><xsl:value-of select="@mode"/></td></tr>
 </xsl:template>

 </xsl:stylesheet>
18.5.1 XSLT (cont)
 Would produce the following result (reformatted for better readability):
 <?xml version="1.0" encoding="UTF-8"?>
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head> <title>setContractData( )</title> </head>
 <body>
   <h1>Service: getContractData( )</h1>
   Parameters (sorted):
   <table border="1">
               <tr><td><b>Name</b></td><td><b>Type</b></td>
               <td><b>Mode</b></td></tr>
               <tr><td>contractId</td><td>long</td><td>in</td></tr>
               <tr><td>firstName</td><td>string</td><td>out</td></tr>
               <tr><td>isActive</td><td>boolean</td><td>out</td></tr>
               <tr><td>lastName</td><td>string</td><td>out</td></tr>
   </table>
 </body>
 </html>

 Which is an HTML page for the service described in the source model (see
  Figure 18-13 for a possible screen dump).
18.5.1 XSLT (cont)
 XSLT transformations work fine for simple code generations and code
  transformations.
 However, experience has shown that they are not ideal for more complicated
  transformations (such as model transformations and code generations for
  many files), for the following reasons:
    Stylesheet templates with the transformation rules are hard to read.
    XSLT is not designed for reading complicated data models out of many files and
       generating hundreds of different results.
      XSLT has no clear separation between reading the input and generating the output.
       So, often you need XSLT transformations for each combination of a source model
       and a destination model (or generated code).
      XSLT is difficult to extend with special processing that occurs in many places.
      XSLT is relatively slow.
      XSLT only processes XML input.
18.5.2 MDSD Tools
 Better alternatives are special tools provided for code
  generation and/or model transformations, some of
  which are open source.
 For example, in one large project we switched from
  XSLT to a tool called openArchitectureWare (see
  [oAW]), which resulted in a remarkable improvement
  in the code generations. The generator code was a lot
  more maintainable, and generations took significantly
  less time.
…
18.6 Avoding Bottlenecks
 In order to scale, large systems have to avoid technical
  and organizational bottlenecks.
   Whatever you set up as your process, you should avoid
    tools, process steps, and artifacts that are singletons (i.e.,
    that exist once for the whole system).
   Don’t introduce a model master who has to accept each
    change before it gets processed
   It should be possible to perform all the transformations
    offline, without being connected to the whole SOA
    system.
18.7 Summary
 Model-driven service development (MDSD) is a perfect way to generate all
  necessary service code (including implementation skeletons, call
    stubs/proxies, test code, and documentation).
   Source models should fulfill all the usual requirements of source code.
   Modeling tools should fulfill all the usual requirements of source code editors.
   You should define your own meta model independent from your specific
    infrastructure and use a corresponding XML notation to decouple service
    specifications from generation of infrastructure-specific code and other
    artifacts.
   It is not enough to provide all the necessary generators. Setting up appropriate
    processes (defining who generates what, and when) is also part of MDSD.
   It’s important to be able to correlate artifacts that belong to the same version of
    software, even if they are generated (or created) by very different people and at
    very different times.
   An enterprise service bus should be able to deal with the fact that not all
    corresponding updates get deployed at the same time.
   XSLT is one, but not necessarily the best, way to generate code. While it works
    well for transferring small XML files into other formats, XSLT’s limitations
    become apparent when dealing with complex models, complex
    transformations, and many files.

More Related Content

What's hot

Architecting and Designing Enterprise Applications
Architecting and Designing Enterprise ApplicationsArchitecting and Designing Enterprise Applications
Architecting and Designing Enterprise ApplicationsGem WeBlog
 
Cmit 350 network design proposal use this document as a guide for f
Cmit 350 network design proposal use this document as a guide for fCmit 350 network design proposal use this document as a guide for f
Cmit 350 network design proposal use this document as a guide for fAMMY30
 
A comparison of the top four enterprise
A comparison of the top four enterpriseA comparison of the top four enterprise
A comparison of the top four enterpriseMohammed Omar
 
MicroStrategy - Effective Business Dashboards
MicroStrategy - Effective Business DashboardsMicroStrategy - Effective Business Dashboards
MicroStrategy - Effective Business DashboardsMicroStrategy Nederland
 
EA as a Change Management Agent
EA as a Change Management AgentEA as a Change Management Agent
EA as a Change Management AgentJerald Burget
 
Database design (conceptual, logical and physical design) unit 2 part 2
Database design (conceptual, logical and physical design)  unit 2 part 2Database design (conceptual, logical and physical design)  unit 2 part 2
Database design (conceptual, logical and physical design) unit 2 part 2Ram Paliwal
 
Technical Architecture
Technical ArchitectureTechnical Architecture
Technical Architecturescmiyer
 
Database development progress(database)
Database development progress(database)Database development progress(database)
Database development progress(database)welcometofacebook
 
SOLIDWORKS reseller Whitepaper by Promedia Systems
SOLIDWORKS reseller Whitepaper by Promedia Systems SOLIDWORKS reseller Whitepaper by Promedia Systems
SOLIDWORKS reseller Whitepaper by Promedia Systems Cavien Clever
 
Introduction to Data Warehousing
Introduction to Data WarehousingIntroduction to Data Warehousing
Introduction to Data WarehousingJason S
 
Informatica and datawarehouse Material
Informatica and datawarehouse MaterialInformatica and datawarehouse Material
Informatica and datawarehouse Materialobieefans
 
The Database Environment Chapter 1
The Database Environment Chapter 1The Database Environment Chapter 1
The Database Environment Chapter 1Jeanie Arnoco
 
The Database Environment Chapter 2
The Database Environment Chapter 2The Database Environment Chapter 2
The Database Environment Chapter 2Jeanie Arnoco
 
Week 7 Database Development Process
Week 7 Database Development ProcessWeek 7 Database Development Process
Week 7 Database Development Processoudesign
 
A 5-step methodology for complex E&P data management
A 5-step methodology for complex E&P data managementA 5-step methodology for complex E&P data management
A 5-step methodology for complex E&P data managementETLSolutions
 
Should ETL Become Obsolete
Should ETL Become ObsoleteShould ETL Become Obsolete
Should ETL Become ObsoleteJerald Burget
 

What's hot (20)

Architecting and Designing Enterprise Applications
Architecting and Designing Enterprise ApplicationsArchitecting and Designing Enterprise Applications
Architecting and Designing Enterprise Applications
 
Cmit 350 network design proposal use this document as a guide for f
Cmit 350 network design proposal use this document as a guide for fCmit 350 network design proposal use this document as a guide for f
Cmit 350 network design proposal use this document as a guide for f
 
A comparison of the top four enterprise
A comparison of the top four enterpriseA comparison of the top four enterprise
A comparison of the top four enterprise
 
Microservices Decomposition Patterns.v1.0.20191009
Microservices Decomposition Patterns.v1.0.20191009Microservices Decomposition Patterns.v1.0.20191009
Microservices Decomposition Patterns.v1.0.20191009
 
MicroStrategy - Effective Business Dashboards
MicroStrategy - Effective Business DashboardsMicroStrategy - Effective Business Dashboards
MicroStrategy - Effective Business Dashboards
 
EA as a Change Management Agent
EA as a Change Management AgentEA as a Change Management Agent
EA as a Change Management Agent
 
Database Life Cycle
Database Life CycleDatabase Life Cycle
Database Life Cycle
 
Database design (conceptual, logical and physical design) unit 2 part 2
Database design (conceptual, logical and physical design)  unit 2 part 2Database design (conceptual, logical and physical design)  unit 2 part 2
Database design (conceptual, logical and physical design) unit 2 part 2
 
Technical Architecture
Technical ArchitectureTechnical Architecture
Technical Architecture
 
Database development progress(database)
Database development progress(database)Database development progress(database)
Database development progress(database)
 
SOLIDWORKS reseller Whitepaper by Promedia Systems
SOLIDWORKS reseller Whitepaper by Promedia Systems SOLIDWORKS reseller Whitepaper by Promedia Systems
SOLIDWORKS reseller Whitepaper by Promedia Systems
 
Introduction to Data Warehousing
Introduction to Data WarehousingIntroduction to Data Warehousing
Introduction to Data Warehousing
 
Informatica and datawarehouse Material
Informatica and datawarehouse MaterialInformatica and datawarehouse Material
Informatica and datawarehouse Material
 
The Database Environment Chapter 1
The Database Environment Chapter 1The Database Environment Chapter 1
The Database Environment Chapter 1
 
The Database Environment Chapter 2
The Database Environment Chapter 2The Database Environment Chapter 2
The Database Environment Chapter 2
 
Week 7 Database Development Process
Week 7 Database Development ProcessWeek 7 Database Development Process
Week 7 Database Development Process
 
Process modelling
Process modellingProcess modelling
Process modelling
 
A 5-step methodology for complex E&P data management
A 5-step methodology for complex E&P data managementA 5-step methodology for complex E&P data management
A 5-step methodology for complex E&P data management
 
Dfd 3
Dfd 3Dfd 3
Dfd 3
 
Should ETL Become Obsolete
Should ETL Become ObsoleteShould ETL Become Obsolete
Should ETL Become Obsolete
 

Viewers also liked

Unemployment in Somaliland Report By Mohamed Muse Haji Abdi
Unemployment in  Somaliland Report By Mohamed Muse Haji AbdiUnemployment in  Somaliland Report By Mohamed Muse Haji Abdi
Unemployment in Somaliland Report By Mohamed Muse Haji AbdiYusuf Mohamed
 
Exploring the Design Process
Exploring the Design ProcessExploring the Design Process
Exploring the Design ProcessStacy Kvernmo
 
Top 10 immigration consultant interview questions and answers
Top 10 immigration consultant interview questions and answersTop 10 immigration consultant interview questions and answers
Top 10 immigration consultant interview questions and answerslouiskeith08
 
Which Color Ensures More Success for your Brand?
Which Color Ensures More Success for your Brand?Which Color Ensures More Success for your Brand?
Which Color Ensures More Success for your Brand?Jim MacLeod
 
Types of unemployment
Types of unemploymentTypes of unemployment
Types of unemploymentFaith Martin
 
User Driven Software Architecture
User Driven Software ArchitectureUser Driven Software Architecture
User Driven Software ArchitectureSimon Guest
 
causes of unemployment
causes of unemploymentcauses of unemployment
causes of unemploymentMAKADIA
 
From Scratch to Launch #2 - Design phase
From Scratch to Launch #2 - Design phaseFrom Scratch to Launch #2 - Design phase
From Scratch to Launch #2 - Design phaseStacy Kvernmo
 
Learning About the Future of Marketing at INBOUND16
Learning About the Future of Marketing at INBOUND16Learning About the Future of Marketing at INBOUND16
Learning About the Future of Marketing at INBOUND16Jim MacLeod
 
The Road to Civil War (1850-1860)
The Road to Civil War (1850-1860)The Road to Civil War (1850-1860)
The Road to Civil War (1850-1860)Tom Richey
 
From customer hostility to customer centricity
From customer hostility to customer centricityFrom customer hostility to customer centricity
From customer hostility to customer centricityHelge Tennø
 
Ppt on unemployment
Ppt on unemploymentPpt on unemployment
Ppt on unemploymentmanav500
 
The State of Sales & Marketing at the 50 Fastest-Growing B2B Companies
The State of Sales & Marketing at the 50 Fastest-Growing B2B CompaniesThe State of Sales & Marketing at the 50 Fastest-Growing B2B Companies
The State of Sales & Marketing at the 50 Fastest-Growing B2B CompaniesMattermark
 

Viewers also liked (15)

Project developing
Project developingProject developing
Project developing
 
Unemployment in Somaliland Report By Mohamed Muse Haji Abdi
Unemployment in  Somaliland Report By Mohamed Muse Haji AbdiUnemployment in  Somaliland Report By Mohamed Muse Haji Abdi
Unemployment in Somaliland Report By Mohamed Muse Haji Abdi
 
Exploring the Design Process
Exploring the Design ProcessExploring the Design Process
Exploring the Design Process
 
Top 10 immigration consultant interview questions and answers
Top 10 immigration consultant interview questions and answersTop 10 immigration consultant interview questions and answers
Top 10 immigration consultant interview questions and answers
 
Which Color Ensures More Success for your Brand?
Which Color Ensures More Success for your Brand?Which Color Ensures More Success for your Brand?
Which Color Ensures More Success for your Brand?
 
Types of unemployment
Types of unemploymentTypes of unemployment
Types of unemployment
 
User Driven Software Architecture
User Driven Software ArchitectureUser Driven Software Architecture
User Driven Software Architecture
 
causes of unemployment
causes of unemploymentcauses of unemployment
causes of unemployment
 
From Scratch to Launch #2 - Design phase
From Scratch to Launch #2 - Design phaseFrom Scratch to Launch #2 - Design phase
From Scratch to Launch #2 - Design phase
 
Learning About the Future of Marketing at INBOUND16
Learning About the Future of Marketing at INBOUND16Learning About the Future of Marketing at INBOUND16
Learning About the Future of Marketing at INBOUND16
 
Unemployment
Unemployment Unemployment
Unemployment
 
The Road to Civil War (1850-1860)
The Road to Civil War (1850-1860)The Road to Civil War (1850-1860)
The Road to Civil War (1850-1860)
 
From customer hostility to customer centricity
From customer hostility to customer centricityFrom customer hostility to customer centricity
From customer hostility to customer centricity
 
Ppt on unemployment
Ppt on unemploymentPpt on unemployment
Ppt on unemployment
 
The State of Sales & Marketing at the 50 Fastest-Growing B2B Companies
The State of Sales & Marketing at the 50 Fastest-Growing B2B CompaniesThe State of Sales & Marketing at the 50 Fastest-Growing B2B Companies
The State of Sales & Marketing at the 50 Fastest-Growing B2B Companies
 

Similar to Lecture 18 - Model-Driven Service Development

Model view-delegates-whitepaper
Model view-delegates-whitepaperModel view-delegates-whitepaper
Model view-delegates-whitepapernilus
 
Service Oriented & Model Driven Architectures
Service Oriented & Model Driven ArchitecturesService Oriented & Model Driven Architectures
Service Oriented & Model Driven ArchitecturesPankaj Saharan
 
Experiment on BPM and SOA transformations
Experiment on BPM and SOA transformationsExperiment on BPM and SOA transformations
Experiment on BPM and SOA transformationsAkira Tanaka
 
Contract First Modeling Services Using Uml
Contract First Modeling Services Using UmlContract First Modeling Services Using Uml
Contract First Modeling Services Using UmlRody Middelkoop
 
Limited Budget but Effective End to End MLOps Practices (Machine Learning Mod...
Limited Budget but Effective End to End MLOps Practices (Machine Learning Mod...Limited Budget but Effective End to End MLOps Practices (Machine Learning Mod...
Limited Budget but Effective End to End MLOps Practices (Machine Learning Mod...IRJET Journal
 
Implementing_S1000D_Best_Business_Practices_Means_Understanding_Your
Implementing_S1000D_Best_Business_Practices_Means_Understanding_YourImplementing_S1000D_Best_Business_Practices_Means_Understanding_Your
Implementing_S1000D_Best_Business_Practices_Means_Understanding_YourMichael Cook
 
CS587 Project - Raychaudhury,Shaalmali
CS587 Project - Raychaudhury,ShaalmaliCS587 Project - Raychaudhury,Shaalmali
CS587 Project - Raychaudhury,Shaalmalisagar.247
 
Applying Code Customizations to Magento 2
Applying Code Customizations to Magento 2 Applying Code Customizations to Magento 2
Applying Code Customizations to Magento 2 Igor Miniailo
 
Managing Complexity and Change with Scalable Software Design
Managing Complexity and Change with Scalable Software DesignManaging Complexity and Change with Scalable Software Design
Managing Complexity and Change with Scalable Software Designlbergmans
 
A Formal Framework for SAAS Customization Based on Multi-Layered Architecture...
A Formal Framework for SAAS Customization Based on Multi-Layered Architecture...A Formal Framework for SAAS Customization Based on Multi-Layered Architecture...
A Formal Framework for SAAS Customization Based on Multi-Layered Architecture...CSCJournals
 
PHP modernization approach generating KDM models from PHP legacy code
PHP modernization approach generating KDM models from PHP legacy codePHP modernization approach generating KDM models from PHP legacy code
PHP modernization approach generating KDM models from PHP legacy codejournalBEEI
 
The Ultimate Guide to Ad0 e103 adobe experience manager sites developer
The Ultimate Guide to Ad0 e103 adobe experience manager sites developerThe Ultimate Guide to Ad0 e103 adobe experience manager sites developer
The Ultimate Guide to Ad0 e103 adobe experience manager sites developerShoanSharma
 
Microsoft BizTalk server seen by the programmer’s eyes
Microsoft BizTalk server seen by the programmer’s eyesMicrosoft BizTalk server seen by the programmer’s eyes
Microsoft BizTalk server seen by the programmer’s eyesSandro Pereira
 
Lecture 9 - SOA in Context
Lecture 9 - SOA in ContextLecture 9 - SOA in Context
Lecture 9 - SOA in Contextphanleson
 
DESIGN AND DEVELOPMENT OF BUSINESS RULES MANAGEMENT SYSTEM (BRMS) USING ATLAN...
DESIGN AND DEVELOPMENT OF BUSINESS RULES MANAGEMENT SYSTEM (BRMS) USING ATLAN...DESIGN AND DEVELOPMENT OF BUSINESS RULES MANAGEMENT SYSTEM (BRMS) USING ATLAN...
DESIGN AND DEVELOPMENT OF BUSINESS RULES MANAGEMENT SYSTEM (BRMS) USING ATLAN...ijcsit
 
P209 leithiser-relationaldb-formal-specifications
P209 leithiser-relationaldb-formal-specificationsP209 leithiser-relationaldb-formal-specifications
P209 leithiser-relationaldb-formal-specificationsBob Leithiser
 
The Clean Architecture
The Clean ArchitectureThe Clean Architecture
The Clean ArchitectureDmytro Turskyi
 
Application Of Distributed Application Challenges
Application Of Distributed Application ChallengesApplication Of Distributed Application Challenges
Application Of Distributed Application ChallengesTrina Simmons
 
PMML - Predictive Model Markup Language
PMML - Predictive Model Markup LanguagePMML - Predictive Model Markup Language
PMML - Predictive Model Markup Languageaguazzel
 

Similar to Lecture 18 - Model-Driven Service Development (20)

Model view-delegates-whitepaper
Model view-delegates-whitepaperModel view-delegates-whitepaper
Model view-delegates-whitepaper
 
Service Oriented & Model Driven Architectures
Service Oriented & Model Driven ArchitecturesService Oriented & Model Driven Architectures
Service Oriented & Model Driven Architectures
 
Experiment on BPM and SOA transformations
Experiment on BPM and SOA transformationsExperiment on BPM and SOA transformations
Experiment on BPM and SOA transformations
 
Contract First Modeling Services Using Uml
Contract First Modeling Services Using UmlContract First Modeling Services Using Uml
Contract First Modeling Services Using Uml
 
Limited Budget but Effective End to End MLOps Practices (Machine Learning Mod...
Limited Budget but Effective End to End MLOps Practices (Machine Learning Mod...Limited Budget but Effective End to End MLOps Practices (Machine Learning Mod...
Limited Budget but Effective End to End MLOps Practices (Machine Learning Mod...
 
Implementing_S1000D_Best_Business_Practices_Means_Understanding_Your
Implementing_S1000D_Best_Business_Practices_Means_Understanding_YourImplementing_S1000D_Best_Business_Practices_Means_Understanding_Your
Implementing_S1000D_Best_Business_Practices_Means_Understanding_Your
 
CS587 Project - Raychaudhury,Shaalmali
CS587 Project - Raychaudhury,ShaalmaliCS587 Project - Raychaudhury,Shaalmali
CS587 Project - Raychaudhury,Shaalmali
 
Applying Code Customizations to Magento 2
Applying Code Customizations to Magento 2 Applying Code Customizations to Magento 2
Applying Code Customizations to Magento 2
 
Managing Complexity and Change with Scalable Software Design
Managing Complexity and Change with Scalable Software DesignManaging Complexity and Change with Scalable Software Design
Managing Complexity and Change with Scalable Software Design
 
A Formal Framework for SAAS Customization Based on Multi-Layered Architecture...
A Formal Framework for SAAS Customization Based on Multi-Layered Architecture...A Formal Framework for SAAS Customization Based on Multi-Layered Architecture...
A Formal Framework for SAAS Customization Based on Multi-Layered Architecture...
 
PHP modernization approach generating KDM models from PHP legacy code
PHP modernization approach generating KDM models from PHP legacy codePHP modernization approach generating KDM models from PHP legacy code
PHP modernization approach generating KDM models from PHP legacy code
 
The Ultimate Guide to Ad0 e103 adobe experience manager sites developer
The Ultimate Guide to Ad0 e103 adobe experience manager sites developerThe Ultimate Guide to Ad0 e103 adobe experience manager sites developer
The Ultimate Guide to Ad0 e103 adobe experience manager sites developer
 
Microsoft BizTalk server seen by the programmer’s eyes
Microsoft BizTalk server seen by the programmer’s eyesMicrosoft BizTalk server seen by the programmer’s eyes
Microsoft BizTalk server seen by the programmer’s eyes
 
Lecture 9 - SOA in Context
Lecture 9 - SOA in ContextLecture 9 - SOA in Context
Lecture 9 - SOA in Context
 
DESIGN AND DEVELOPMENT OF BUSINESS RULES MANAGEMENT SYSTEM (BRMS) USING ATLAN...
DESIGN AND DEVELOPMENT OF BUSINESS RULES MANAGEMENT SYSTEM (BRMS) USING ATLAN...DESIGN AND DEVELOPMENT OF BUSINESS RULES MANAGEMENT SYSTEM (BRMS) USING ATLAN...
DESIGN AND DEVELOPMENT OF BUSINESS RULES MANAGEMENT SYSTEM (BRMS) USING ATLAN...
 
P209 leithiser-relationaldb-formal-specifications
P209 leithiser-relationaldb-formal-specificationsP209 leithiser-relationaldb-formal-specifications
P209 leithiser-relationaldb-formal-specifications
 
The Clean Architecture
The Clean ArchitectureThe Clean Architecture
The Clean Architecture
 
Application Of Distributed Application Challenges
Application Of Distributed Application ChallengesApplication Of Distributed Application Challenges
Application Of Distributed Application Challenges
 
PMML - Predictive Model Markup Language
PMML - Predictive Model Markup LanguagePMML - Predictive Model Markup Language
PMML - Predictive Model Markup Language
 
DDS-TSN OMG Request for Proposals (RFP)
DDS-TSN OMG Request for Proposals (RFP)DDS-TSN OMG Request for Proposals (RFP)
DDS-TSN OMG Request for Proposals (RFP)
 

More from phanleson

Learning spark ch01 - Introduction to Data Analysis with Spark
Learning spark ch01 - Introduction to Data Analysis with SparkLearning spark ch01 - Introduction to Data Analysis with Spark
Learning spark ch01 - Introduction to Data Analysis with Sparkphanleson
 
Firewall - Network Defense in Depth Firewalls
Firewall - Network Defense in Depth FirewallsFirewall - Network Defense in Depth Firewalls
Firewall - Network Defense in Depth Firewallsphanleson
 
Mobile Security - Wireless hacking
Mobile Security - Wireless hackingMobile Security - Wireless hacking
Mobile Security - Wireless hackingphanleson
 
Authentication in wireless - Security in Wireless Protocols
Authentication in wireless - Security in Wireless ProtocolsAuthentication in wireless - Security in Wireless Protocols
Authentication in wireless - Security in Wireless Protocolsphanleson
 
E-Commerce Security - Application attacks - Server Attacks
E-Commerce Security - Application attacks - Server AttacksE-Commerce Security - Application attacks - Server Attacks
E-Commerce Security - Application attacks - Server Attacksphanleson
 
Hacking web applications
Hacking web applicationsHacking web applications
Hacking web applicationsphanleson
 
HBase In Action - Chapter 04: HBase table design
HBase In Action - Chapter 04: HBase table designHBase In Action - Chapter 04: HBase table design
HBase In Action - Chapter 04: HBase table designphanleson
 
HBase In Action - Chapter 10 - Operations
HBase In Action - Chapter 10 - OperationsHBase In Action - Chapter 10 - Operations
HBase In Action - Chapter 10 - Operationsphanleson
 
Hbase in action - Chapter 09: Deploying HBase
Hbase in action - Chapter 09: Deploying HBaseHbase in action - Chapter 09: Deploying HBase
Hbase in action - Chapter 09: Deploying HBasephanleson
 
Learning spark ch11 - Machine Learning with MLlib
Learning spark ch11 - Machine Learning with MLlibLearning spark ch11 - Machine Learning with MLlib
Learning spark ch11 - Machine Learning with MLlibphanleson
 
Learning spark ch10 - Spark Streaming
Learning spark ch10 - Spark StreamingLearning spark ch10 - Spark Streaming
Learning spark ch10 - Spark Streamingphanleson
 
Learning spark ch09 - Spark SQL
Learning spark ch09 - Spark SQLLearning spark ch09 - Spark SQL
Learning spark ch09 - Spark SQLphanleson
 
Learning spark ch07 - Running on a Cluster
Learning spark ch07 - Running on a ClusterLearning spark ch07 - Running on a Cluster
Learning spark ch07 - Running on a Clusterphanleson
 
Learning spark ch06 - Advanced Spark Programming
Learning spark ch06 - Advanced Spark ProgrammingLearning spark ch06 - Advanced Spark Programming
Learning spark ch06 - Advanced Spark Programmingphanleson
 
Learning spark ch05 - Loading and Saving Your Data
Learning spark ch05 - Loading and Saving Your DataLearning spark ch05 - Loading and Saving Your Data
Learning spark ch05 - Loading and Saving Your Dataphanleson
 
Learning spark ch04 - Working with Key/Value Pairs
Learning spark ch04 - Working with Key/Value PairsLearning spark ch04 - Working with Key/Value Pairs
Learning spark ch04 - Working with Key/Value Pairsphanleson
 
Learning spark ch01 - Introduction to Data Analysis with Spark
Learning spark ch01 - Introduction to Data Analysis with SparkLearning spark ch01 - Introduction to Data Analysis with Spark
Learning spark ch01 - Introduction to Data Analysis with Sparkphanleson
 
Hướng Dẫn Đăng Ký LibertaGia - A guide and introduciton about Libertagia
Hướng Dẫn Đăng Ký LibertaGia - A guide and introduciton about LibertagiaHướng Dẫn Đăng Ký LibertaGia - A guide and introduciton about Libertagia
Hướng Dẫn Đăng Ký LibertaGia - A guide and introduciton about Libertagiaphanleson
 
Lecture 1 - Getting to know XML
Lecture 1 - Getting to know XMLLecture 1 - Getting to know XML
Lecture 1 - Getting to know XMLphanleson
 
Lecture 4 - Adding XTHML for the Web
Lecture  4 - Adding XTHML for the WebLecture  4 - Adding XTHML for the Web
Lecture 4 - Adding XTHML for the Webphanleson
 

More from phanleson (20)

Learning spark ch01 - Introduction to Data Analysis with Spark
Learning spark ch01 - Introduction to Data Analysis with SparkLearning spark ch01 - Introduction to Data Analysis with Spark
Learning spark ch01 - Introduction to Data Analysis with Spark
 
Firewall - Network Defense in Depth Firewalls
Firewall - Network Defense in Depth FirewallsFirewall - Network Defense in Depth Firewalls
Firewall - Network Defense in Depth Firewalls
 
Mobile Security - Wireless hacking
Mobile Security - Wireless hackingMobile Security - Wireless hacking
Mobile Security - Wireless hacking
 
Authentication in wireless - Security in Wireless Protocols
Authentication in wireless - Security in Wireless ProtocolsAuthentication in wireless - Security in Wireless Protocols
Authentication in wireless - Security in Wireless Protocols
 
E-Commerce Security - Application attacks - Server Attacks
E-Commerce Security - Application attacks - Server AttacksE-Commerce Security - Application attacks - Server Attacks
E-Commerce Security - Application attacks - Server Attacks
 
Hacking web applications
Hacking web applicationsHacking web applications
Hacking web applications
 
HBase In Action - Chapter 04: HBase table design
HBase In Action - Chapter 04: HBase table designHBase In Action - Chapter 04: HBase table design
HBase In Action - Chapter 04: HBase table design
 
HBase In Action - Chapter 10 - Operations
HBase In Action - Chapter 10 - OperationsHBase In Action - Chapter 10 - Operations
HBase In Action - Chapter 10 - Operations
 
Hbase in action - Chapter 09: Deploying HBase
Hbase in action - Chapter 09: Deploying HBaseHbase in action - Chapter 09: Deploying HBase
Hbase in action - Chapter 09: Deploying HBase
 
Learning spark ch11 - Machine Learning with MLlib
Learning spark ch11 - Machine Learning with MLlibLearning spark ch11 - Machine Learning with MLlib
Learning spark ch11 - Machine Learning with MLlib
 
Learning spark ch10 - Spark Streaming
Learning spark ch10 - Spark StreamingLearning spark ch10 - Spark Streaming
Learning spark ch10 - Spark Streaming
 
Learning spark ch09 - Spark SQL
Learning spark ch09 - Spark SQLLearning spark ch09 - Spark SQL
Learning spark ch09 - Spark SQL
 
Learning spark ch07 - Running on a Cluster
Learning spark ch07 - Running on a ClusterLearning spark ch07 - Running on a Cluster
Learning spark ch07 - Running on a Cluster
 
Learning spark ch06 - Advanced Spark Programming
Learning spark ch06 - Advanced Spark ProgrammingLearning spark ch06 - Advanced Spark Programming
Learning spark ch06 - Advanced Spark Programming
 
Learning spark ch05 - Loading and Saving Your Data
Learning spark ch05 - Loading and Saving Your DataLearning spark ch05 - Loading and Saving Your Data
Learning spark ch05 - Loading and Saving Your Data
 
Learning spark ch04 - Working with Key/Value Pairs
Learning spark ch04 - Working with Key/Value PairsLearning spark ch04 - Working with Key/Value Pairs
Learning spark ch04 - Working with Key/Value Pairs
 
Learning spark ch01 - Introduction to Data Analysis with Spark
Learning spark ch01 - Introduction to Data Analysis with SparkLearning spark ch01 - Introduction to Data Analysis with Spark
Learning spark ch01 - Introduction to Data Analysis with Spark
 
Hướng Dẫn Đăng Ký LibertaGia - A guide and introduciton about Libertagia
Hướng Dẫn Đăng Ký LibertaGia - A guide and introduciton about LibertagiaHướng Dẫn Đăng Ký LibertaGia - A guide and introduciton about Libertagia
Hướng Dẫn Đăng Ký LibertaGia - A guide and introduciton about Libertagia
 
Lecture 1 - Getting to know XML
Lecture 1 - Getting to know XMLLecture 1 - Getting to know XML
Lecture 1 - Getting to know XML
 
Lecture 4 - Adding XTHML for the Web
Lecture  4 - Adding XTHML for the WebLecture  4 - Adding XTHML for the Web
Lecture 4 - Adding XTHML for the Web
 

Recently uploaded

ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in PharmacyASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in PharmacySumit Tiwari
 
The basics of sentences session 8pptx.pptx
The basics of sentences session 8pptx.pptxThe basics of sentences session 8pptx.pptx
The basics of sentences session 8pptx.pptxheathfieldcps1
 
The First National K12 TUG March 6 2024.pdf
The First National K12 TUG March 6 2024.pdfThe First National K12 TUG March 6 2024.pdf
The First National K12 TUG March 6 2024.pdfdogden2
 
3.12.24 Freedom Summer in Mississippi.pptx
3.12.24 Freedom Summer in Mississippi.pptx3.12.24 Freedom Summer in Mississippi.pptx
3.12.24 Freedom Summer in Mississippi.pptxmary850239
 
BBA 205 BUSINESS ENVIRONMENT UNIT I.pptx
BBA 205 BUSINESS ENVIRONMENT UNIT I.pptxBBA 205 BUSINESS ENVIRONMENT UNIT I.pptx
BBA 205 BUSINESS ENVIRONMENT UNIT I.pptxProf. Kanchan Kumari
 
Auchitya Theory by Kshemendra Indian Poetics
Auchitya Theory by Kshemendra Indian PoeticsAuchitya Theory by Kshemendra Indian Poetics
Auchitya Theory by Kshemendra Indian PoeticsDhatriParmar
 
DNA and RNA , Structure, Functions, Types, difference, Similarities, Protein ...
DNA and RNA , Structure, Functions, Types, difference, Similarities, Protein ...DNA and RNA , Structure, Functions, Types, difference, Similarities, Protein ...
DNA and RNA , Structure, Functions, Types, difference, Similarities, Protein ...AKSHAYMAGAR17
 
Material Remains as Source of Ancient Indian History & Culture.ppt
Material Remains as Source of Ancient Indian History & Culture.pptMaterial Remains as Source of Ancient Indian History & Culture.ppt
Material Remains as Source of Ancient Indian History & Culture.pptBanaras Hindu University
 
ICS2208 Lecture4 Intelligent Interface Agents.pdf
ICS2208 Lecture4 Intelligent Interface Agents.pdfICS2208 Lecture4 Intelligent Interface Agents.pdf
ICS2208 Lecture4 Intelligent Interface Agents.pdfVanessa Camilleri
 
LEAD5623 The Economics of Community Coll
LEAD5623 The Economics of Community CollLEAD5623 The Economics of Community Coll
LEAD5623 The Economics of Community CollDr. Bruce A. Johnson
 
Arti Languages Pre Seed Send Ahead Pitchdeck 2024.pdf
Arti Languages Pre Seed Send Ahead Pitchdeck 2024.pdfArti Languages Pre Seed Send Ahead Pitchdeck 2024.pdf
Arti Languages Pre Seed Send Ahead Pitchdeck 2024.pdfwill854175
 
2024.03.16 How to write better quality materials for your learners ELTABB San...
2024.03.16 How to write better quality materials for your learners ELTABB San...2024.03.16 How to write better quality materials for your learners ELTABB San...
2024.03.16 How to write better quality materials for your learners ELTABB San...Sandy Millin
 
AI Uses and Misuses: Academic and Workplace Applications
AI Uses and Misuses: Academic and Workplace ApplicationsAI Uses and Misuses: Academic and Workplace Applications
AI Uses and Misuses: Academic and Workplace ApplicationsStella Lee
 
Awards Presentation 2024 - March 12 2024
Awards Presentation 2024 - March 12 2024Awards Presentation 2024 - March 12 2024
Awards Presentation 2024 - March 12 2024bsellato
 
Pharmacology chapter No 7 full notes.pdf
Pharmacology chapter No 7 full notes.pdfPharmacology chapter No 7 full notes.pdf
Pharmacology chapter No 7 full notes.pdfSumit Tiwari
 
3.14.24 Gender Discrimination and Gender Inequity.pptx
3.14.24 Gender Discrimination and Gender Inequity.pptx3.14.24 Gender Discrimination and Gender Inequity.pptx
3.14.24 Gender Discrimination and Gender Inequity.pptxmary850239
 
Alamkara theory by Bhamaha Indian Poetics (1).pptx
Alamkara theory by Bhamaha Indian Poetics (1).pptxAlamkara theory by Bhamaha Indian Poetics (1).pptx
Alamkara theory by Bhamaha Indian Poetics (1).pptxDhatriParmar
 
The OERs: Transforming Education for Sustainable Future by Dr. Sarita Anand
The OERs: Transforming Education for Sustainable Future by Dr. Sarita AnandThe OERs: Transforming Education for Sustainable Future by Dr. Sarita Anand
The OERs: Transforming Education for Sustainable Future by Dr. Sarita AnandDr. Sarita Anand
 

Recently uploaded (20)

ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in PharmacyASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
 
The basics of sentences session 8pptx.pptx
The basics of sentences session 8pptx.pptxThe basics of sentences session 8pptx.pptx
The basics of sentences session 8pptx.pptx
 
The First National K12 TUG March 6 2024.pdf
The First National K12 TUG March 6 2024.pdfThe First National K12 TUG March 6 2024.pdf
The First National K12 TUG March 6 2024.pdf
 
3.12.24 Freedom Summer in Mississippi.pptx
3.12.24 Freedom Summer in Mississippi.pptx3.12.24 Freedom Summer in Mississippi.pptx
3.12.24 Freedom Summer in Mississippi.pptx
 
BBA 205 BUSINESS ENVIRONMENT UNIT I.pptx
BBA 205 BUSINESS ENVIRONMENT UNIT I.pptxBBA 205 BUSINESS ENVIRONMENT UNIT I.pptx
BBA 205 BUSINESS ENVIRONMENT UNIT I.pptx
 
Auchitya Theory by Kshemendra Indian Poetics
Auchitya Theory by Kshemendra Indian PoeticsAuchitya Theory by Kshemendra Indian Poetics
Auchitya Theory by Kshemendra Indian Poetics
 
DNA and RNA , Structure, Functions, Types, difference, Similarities, Protein ...
DNA and RNA , Structure, Functions, Types, difference, Similarities, Protein ...DNA and RNA , Structure, Functions, Types, difference, Similarities, Protein ...
DNA and RNA , Structure, Functions, Types, difference, Similarities, Protein ...
 
Material Remains as Source of Ancient Indian History & Culture.ppt
Material Remains as Source of Ancient Indian History & Culture.pptMaterial Remains as Source of Ancient Indian History & Culture.ppt
Material Remains as Source of Ancient Indian History & Culture.ppt
 
ICS2208 Lecture4 Intelligent Interface Agents.pdf
ICS2208 Lecture4 Intelligent Interface Agents.pdfICS2208 Lecture4 Intelligent Interface Agents.pdf
ICS2208 Lecture4 Intelligent Interface Agents.pdf
 
LEAD5623 The Economics of Community Coll
LEAD5623 The Economics of Community CollLEAD5623 The Economics of Community Coll
LEAD5623 The Economics of Community Coll
 
Problems on Mean,Mode,Median Standard Deviation
Problems on Mean,Mode,Median Standard DeviationProblems on Mean,Mode,Median Standard Deviation
Problems on Mean,Mode,Median Standard Deviation
 
Arti Languages Pre Seed Send Ahead Pitchdeck 2024.pdf
Arti Languages Pre Seed Send Ahead Pitchdeck 2024.pdfArti Languages Pre Seed Send Ahead Pitchdeck 2024.pdf
Arti Languages Pre Seed Send Ahead Pitchdeck 2024.pdf
 
2024.03.16 How to write better quality materials for your learners ELTABB San...
2024.03.16 How to write better quality materials for your learners ELTABB San...2024.03.16 How to write better quality materials for your learners ELTABB San...
2024.03.16 How to write better quality materials for your learners ELTABB San...
 
AI Uses and Misuses: Academic and Workplace Applications
AI Uses and Misuses: Academic and Workplace ApplicationsAI Uses and Misuses: Academic and Workplace Applications
AI Uses and Misuses: Academic and Workplace Applications
 
Awards Presentation 2024 - March 12 2024
Awards Presentation 2024 - March 12 2024Awards Presentation 2024 - March 12 2024
Awards Presentation 2024 - March 12 2024
 
Pharmacology chapter No 7 full notes.pdf
Pharmacology chapter No 7 full notes.pdfPharmacology chapter No 7 full notes.pdf
Pharmacology chapter No 7 full notes.pdf
 
3.14.24 Gender Discrimination and Gender Inequity.pptx
3.14.24 Gender Discrimination and Gender Inequity.pptx3.14.24 Gender Discrimination and Gender Inequity.pptx
3.14.24 Gender Discrimination and Gender Inequity.pptx
 
Alamkara theory by Bhamaha Indian Poetics (1).pptx
Alamkara theory by Bhamaha Indian Poetics (1).pptxAlamkara theory by Bhamaha Indian Poetics (1).pptx
Alamkara theory by Bhamaha Indian Poetics (1).pptx
 
The OERs: Transforming Education for Sustainable Future by Dr. Sarita Anand
The OERs: Transforming Education for Sustainable Future by Dr. Sarita AnandThe OERs: Transforming Education for Sustainable Future by Dr. Sarita Anand
The OERs: Transforming Education for Sustainable Future by Dr. Sarita Anand
 
ANOVA Parametric test: Biostatics and Research Methodology
ANOVA Parametric test: Biostatics and Research MethodologyANOVA Parametric test: Biostatics and Research Methodology
ANOVA Parametric test: Biostatics and Research Methodology
 

Lecture 18 - Model-Driven Service Development

  • 1. Book Author: Nicolai M. Josuttis Chapter Eighteen: Model-Driven Service Development IT-Slideshares http://it-slideshares.blogspot.com/
  • 2. 18.0 Introduction to MDSD  Service interfaces in heterogeneous environments require a lot of code.  Most of this code often has the same structure, differing only according to the different parameters, exceptions, and other configuration data.  This is a perfect situation for the application of code generators, or, to use a term that is more hype, model- driven service development (MDSD).  Model-driven service development encompasses code both for the provider and for the consumers.
  • 3. 18.1 Generated Service Code  Because SOA is a concept for heterogeneous environments, you might need a lot of different code to implement and call a service.  The structure of the code is usually pretty much the same for any given platform.  Code for two different services will differ only in the specific data transferred , including aspects such as message exchange pattern.  The code that deals with this data conceptually will be pretty much the same.  You could use libraries and frameworks to deal with the commonalities but it has some drawback  should generate such code based on a service description.  Code generated for a service might include (but is not limited to):  Code that provides the framework for implementation details of the service.  Code that provides the ability to call a service.  Code that allows you to deal with the service inside the infrastructure,  Code that provides a framework for tests.  Documentation, which is strictly not code but a result of a generator working on a service description. Scripts for the processing of generated artifacts during build and deployment.  Figure 18.1 demonstrates a possible MDSD approach.
  • 4. 18.2 Modeling Services  The idea of generating code is pretty old.  Following the rule “Three Strikes and You Automate” this is a common mechanism to avoid doing the same work again and again.  However, to be a bit more concrete, let’s dig deeper into the general concepts of code generation and model-driven software development for services.
  • 5. 18.2.1 Terminology  If you compare two hard-coded implementations of a service (or of a service call), you can identify three types of code:  Generic code that is the same for each implementation.  Schematic code that has the same structure but varies somewhat according to the concrete situation.  Code that has no commonalities.  Frequently, the same task can be performed using either generic code or schematic code.  The following example highlights the difference between the implementations.  With a generic approach logName(service.getName( )); for (int i=0; i<service.getParams( ).getSize( ); ++i) { Param param = service.getParam(i); logParam (param.getName(), param.getValue( ).asString( )); }  With a schematic approach. logName("getContractData"); logParam ("contractId", contractId.asString( )); logParam ("firstName", firstName); logParam ("lastName", lastName); logParam ("isActive", isActive ? "true" : "false"); ...  Both forms have pros and cons.  Which solution is preferable depends on the exact circumstances; there is no hardand- fast rule.
  • 6. 18.2.1 Terminology (Cont)  Generic code can usually be part of a framework because it does not have to change for every service instance.  In contrast, schematic code is specific to a service instance and has to be generated from a formal description of the service (defining the service name, parameter names, and parameter types).  The format of the source can vary; for example, it can be a UML class (see Figure 18-2) or an XML file (see Figure 18-3).  Regardless of its format, such a source is called a model (because it abstracts implementation details).
  • 7. 18.2.1 Terminology (Cont)  Beside of its format , a model usually has a specific structure.  The structure of a model is called a meta model.  In other words , a metal model defines the formal structure and element of a model.  A metal model for the preceding figures might look like figure 18.4  As you have seen, there are very different ways to formulate a model.  The concrete notation used to specify a model is called a modeling language or domain-specific language(DSL)  The code generated out of a source (model) is usually called a generation , and you can transform one model into another model , which is usually called a transformation.  Some model-driven approaches distinguish between platform-independent models (PIMs) and platform-specific models (PSMs)  In practice , it’s difficult to make a black-and-white distinction between PIMs and PSMs , because models are usually specific to some platform aspects while independent from other platform aspects.  Note also that transformations are not necessarily bidirectional.  MDSD usually is not able to perform round-trip processing.
  • 8. 18.2.2 The Model-Driven Tool Chain  The notation (DSL) that you use for your models will impact your choice of tools, because there are specific tools that allow you to operate directly on the abstraction layer of specific notations.  For example,  For WSDL there are special tools that allow you to create WSDL files using special (even graphical) IDEs.  Drawback is hard to read and maintain.  Advantage ,that the tools will assist you in keeping the resulting model well formed.  In general, for services very different tools and views can be appropriate.  Note : it is usually not appropriate for defining signatures  A model should not depend on one specific tool.  Ideally there is freedom of choice, and developers can use their favorite text editors, spreadsheet tools, UML tools, XML editors, and IDEs. This contributes to acceptance and development performance.  The usual rules for source code regarding configuration management apply:  The tools should have very short startup periods so that users can use them to perform small modifications quickly.  The tool should have an appropriate human-machine interface (HMI), so that a minimal number of actions (clicks, text input, etc.) are required from the user to get the desired behavior.  The models must be versionable so that you can maintain and distinguish between different versions under development or in production.  The models should support team development,  Ideally, models should have a notation that allows you to edit them with an ordinary text editor.  All configuration-management tools can then work with the models and even perform merges or comparisons.
  • 9. 18.3 Meta Models in Practice  In practice, it is a good idea to define an initial meta model pretty early on.  This meta model should define the different abilities and properties of specified services in your concrete SOA.  A very trivial meta model was shown in Figure 18-4. More practical meta models might, in addition, do the following:  Provide the ability to group services and service operations.  Define a type system that defines fundamental data types and the way they can be composed (for structures and lists).  Provide all information required to manage services (e.g., specifying providers and consumers, contracts, SLAs, and so on).  Distinguish between abstractions and instances of certain kinds of information.  Let’s look at a few (still simplified) examples of what a SOA meta model might look like in practice.  Figure 18-5 mainly deals with the type system.
  • 10. 18.3 Meta Models in Practice (Cont)  A meta model that represents the relationship between services and systems. (Figure 18-6)  To deal with an initial meta model, you don’t need very sophisticated tools. (Figure 18.7)  If you later introduce different types of service specifications, you only have to provide a way to transfer these specifications into your model notation. (Figure 18.8)
  • 11. 18.4 Setting Up MDSD Processes
  • 12. 18.4.1 Consumer-Driven Transformations  Consumer-driven transformations (where those who need the result of a transformation perform it) are usually the easiest to establish as companywide policies.  The consumers only need access to the source (model) and the generator(s).  An added benefit is that the consumers have the understanding and the infrastructure to verify the generated result.  However, this approach has some limitations:  The consumer has to know when a new transformation is necessary.  There might be a security requirement that a consumer should not see the source model.  If the transformation is complicated (includes manual steps) or takes a long time, each consumer may have to invest the same significant effort.  Figure 18-9 demonstrates an example of a consumer-driven transformation.
  • 13. 18.4.2 Provider-Driven Transformations  Provider-driven transformations (where those who define the source of a transformation perform it) solve the problem of multiple transformations for each consumer.  However, they also have some drawbacks:  Verification of the generated code is difficult (if not impossible).  Unnecessary transformations might happen.  If the generators are modified, the provider has to know that a new transformation is necessary.  If the service interface changes, the consumers have to perform corresponding fixes to avoid breaking the next build.  Figure 18-10 demonstrates what the example in Figure 18-9 would look like if the transformations were provider-driven.
  • 14. 18.4.3 Third-Party-Driven Transformations  Third-party-driven transformations (where a separate team performs the transformations) are often appropriate when there is a build team that integrates source code from different departments as part of an iterative software development process.  The nightly builds might include the necessary code generations.  The advantage of this approach :  Both source model and generator modifications result in new corresponding code.  In addition, the build team should be able to verify the result.  Some drawbacks of this approach :  Consuming systems have to be integrated into the general build process.  If the service interface changes, the consumers have to perform corresponding fixes to avoid breaking the next build.  Setting up nightly builds requires effort and time (although this task probably needs to be performed regardless of whether or not you’re using this transformation strategy).
  • 15. 18.4.4 MDSD Processes in Practice  In practice, MDSD processes usually involve a mixture of all these approaches.  There is no perfect transformation policy.  Instead, you have to decide on a case-by-case basis on the corresponding policy to set up the necessary processes.  Transformation processes might even be split into two different steps, so that, for example, a service provider generates an intermediate WSDL file that the consumer then uses to generate its platform-specific code.
  • 16. 18.4.5 Labeling  Scenario :  In large teams, you need configuration-management support so that you can deal with different versions of the same models and generated artifacts   You have to be able to identify all the different artifacts (models, generated code, hand-written code deployment information, and so on) that belong together.  What are you need ?:  You need a very clear way to identify which transformation result (code or model) belongs to which transformation source (model).  What ?  Consequence :  You should be able to identify all the related artifacts with one label or a set of corresponding labels.  Note that in practice labeling should also include the result of a transformation.  Alternatively, instead of labeling the results, you might label the generators to provide traceability for all artifacts.
  • 17. 18.4.6 Debugging  It is key that the generated code is well formed and readable.  This includes generating comments that explain what’s happening.  Without them, only the implementer of the generator will be able to debug the generated code.  Far too often, concrete code-generation policies are exactly the opposite of what is useful  Generators create very condensed code  Using no empty lines or comments because readability is not considered to be an issue  But even people who implement generators make mistakes, and it’s important to be able to follow the data flow of all software.  The only excuse for not having well-structured generated code is when the debuggers operate on the same abstraction layer as the modeling language. (Example with BPEL engines and BPEL IDE)
  • 18. 18.4.7 Manually Modified Generated Code  Sometimes it is necessary to modify generated code by hand.  Example : A skeleton file will contain both generated and manually created code.  Initially, this is not a problem.  Typically you generate skeleton code only once  no risk.  When the generated code has to be changed due to a modification of the source model  You have to regenerate the skeleton code.  There are many approaches to deal with this problem:  Use different files  Code provided for modification is physically separated from code that is completely generated.  Use protected areas  Inside the generated code, you mark the beginning and end of each protected area, indicating where manual modifications are allowed public void changeAddress (Address newAddress) { //==> Begin Protected Area CustomerService.changeAddress //==> End Protected Area CustomerService.changeAddress }  Generate once  A third approach is to avoid regenerating the skeleton code.  Merge generated and manual code  Tries to merge modifications of the skeleton code with manual extensions using a configuration- management tool’s merge tool.  None of these approaches is perfect, and you’ll have to figure out which one is best for your particular situation.
  • 19. 18.4.8 The Code-Generation Granularity Dilemma  Because services should be self-contained, it is usually a good idea to have separate files for each service.  In addition, it might help when the artifacts generated from these files are separated accordingly. This helps to isolate necessary generations when source files change.  In addition, you might want to separate:  Code for different platforms  Skeleton from stub code  Declarations and interfaces from implementations  Following this advice :  Skeleton, stub, and test code is created for each platform, as well as a dummy implementation plus common interface files for some of these files.  A file is created for each data type used in the service.  Build files (such as makefiles) are generated.  Additional files may be created for the C++ platform, because the code is separated into header and definition files.  Some drawbacks of this approach :  It’s hard to understand the code organization  A lot of files must be processed when creating, deploying, and running code.  Finding the right granularity is not easy.  What helps is a good organization of the code, so that your directory structure matches your process structure.  This is one reason to separate the sources and results of transformations into different directories.
  • 20. 18.4.9 Deployment and Robustness  Usually, you can’t guarantee that all service participants (providers and consumers) will deploy modifications at the same time.  Each system may have its own (model-driven) software development process, so it may take varying amounts of time for modifications to be made (see Figure 18-11).  This consideration has two important consequences:  An enterprise service bus, at least in a test environment, must be able to deal with inconsistencies.  It is almost impossible to make backward-incompatible modifications that impact all services.
  • 21. 18.5 Tools  Because nowadays, almost every modeling language uses XML-based formats, one tool for transformations and/or code generations might be obvious: eXtensible Stylesheet Language Transformations, or XSLT.  XSLT, however, has some limitations, which In this chapter will discuss more. This chapter’ll then present an alternative.
  • 22. 18.5.1 XSLT  An XSLT processor transforms one or more XML files into one or more result files, which might be in XML or any other text form.  The transformations are defined by one or more XSLT stylesheet files.  These files provide templates for the resulting code, spiced with control structures to iterate over input tokens and placeholders to fill in certain data derived from the source files (see Figure 18-12).
  • 23. 18.5.1 XSLT (cont)  For example, say you had the following service description: <service name="getContractData"> <param mode="in"> <name>contractId</name> <type>long</type> </param> <param mode="out"> <name>firstName</name> <type>string</type> </param> <param mode="out"> <name>lastName</name> <type>string</type> </param> <param mode="out"> <name>isActive</name> <type>boolean</type> </param> </service>
  • 24. 18.5.1 XSLT (cont)  A transformation according to the following stylesheet: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template match="/service"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title><xsl:value-of select="@name"/>( )</title> </head> <body> <h1>Service: <xsl:value-of select="@name"/>( )</h1> Parameters (sorted): <table border="1"> <tr><td><b>Name</b></td><td><b>Type</b></td> <td><b>Mode</b></td></tr> <xsl:apply-templates select="param"> <xsl:sort select="name" /> </xsl:apply-templates> </table> </body> </html> </xsl:template> <xsl:template match="param"> <tr><td><xsl:value-of select="name"/></td> <td><xsl:value-of select="type"/></td <td><xsl:value-of select="@mode"/></td></tr> </xsl:template> </xsl:stylesheet>
  • 25. 18.5.1 XSLT (cont)  Would produce the following result (reformatted for better readability): <?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>setContractData( )</title> </head> <body> <h1>Service: getContractData( )</h1> Parameters (sorted): <table border="1"> <tr><td><b>Name</b></td><td><b>Type</b></td> <td><b>Mode</b></td></tr> <tr><td>contractId</td><td>long</td><td>in</td></tr> <tr><td>firstName</td><td>string</td><td>out</td></tr> <tr><td>isActive</td><td>boolean</td><td>out</td></tr> <tr><td>lastName</td><td>string</td><td>out</td></tr> </table> </body> </html>  Which is an HTML page for the service described in the source model (see Figure 18-13 for a possible screen dump).
  • 26. 18.5.1 XSLT (cont)  XSLT transformations work fine for simple code generations and code transformations.  However, experience has shown that they are not ideal for more complicated transformations (such as model transformations and code generations for many files), for the following reasons:  Stylesheet templates with the transformation rules are hard to read.  XSLT is not designed for reading complicated data models out of many files and generating hundreds of different results.  XSLT has no clear separation between reading the input and generating the output. So, often you need XSLT transformations for each combination of a source model and a destination model (or generated code).  XSLT is difficult to extend with special processing that occurs in many places.  XSLT is relatively slow.  XSLT only processes XML input.
  • 27. 18.5.2 MDSD Tools  Better alternatives are special tools provided for code generation and/or model transformations, some of which are open source.  For example, in one large project we switched from XSLT to a tool called openArchitectureWare (see [oAW]), which resulted in a remarkable improvement in the code generations. The generator code was a lot more maintainable, and generations took significantly less time. …
  • 28. 18.6 Avoding Bottlenecks  In order to scale, large systems have to avoid technical and organizational bottlenecks.  Whatever you set up as your process, you should avoid tools, process steps, and artifacts that are singletons (i.e., that exist once for the whole system).  Don’t introduce a model master who has to accept each change before it gets processed  It should be possible to perform all the transformations offline, without being connected to the whole SOA system.
  • 29. 18.7 Summary  Model-driven service development (MDSD) is a perfect way to generate all necessary service code (including implementation skeletons, call stubs/proxies, test code, and documentation).  Source models should fulfill all the usual requirements of source code.  Modeling tools should fulfill all the usual requirements of source code editors.  You should define your own meta model independent from your specific infrastructure and use a corresponding XML notation to decouple service specifications from generation of infrastructure-specific code and other artifacts.  It is not enough to provide all the necessary generators. Setting up appropriate processes (defining who generates what, and when) is also part of MDSD.  It’s important to be able to correlate artifacts that belong to the same version of software, even if they are generated (or created) by very different people and at very different times.  An enterprise service bus should be able to deal with the fact that not all corresponding updates get deployed at the same time.  XSLT is one, but not necessarily the best, way to generate code. While it works well for transferring small XML files into other formats, XSLT’s limitations become apparent when dealing with complex models, complex transformations, and many files.

Editor's Notes

  1. Describe for Figure 18.1 Figure 18-1 demonstrates a possible MDSD approach. While some teams design their services in a Rational Rose Repository, others use Web Services tools to create initial WSDL files. Because the Rose Repository includes the whole contract, a generator exists to create Word documentation out of it. Both Rose and WSDL can also be transformed into an intermediate format that serves as a base for code generators for specific platforms (Java, C, C++). In addition, some registry code for the ESB is generated, and via the Java code an infrastructure-specific WSDL file is generated.*
  2. For more Details Web Services Federation Language. http://c2.com/cgi/wiki?ThreeStrikes. Stahl, Thomas and Markus Völter. 2006. Model-Driven Software Development: Technology, Engineering, Management. Hoboken, NJ: John Wiley &amp; Sons.
  3. Describe for figure 18.4Using the UML notation, this meta model defines that a service has a name and multiple parameters. Each parameter has a mode (“in” or “out”), a name, and a type to which it refers. Note that only the XML notation in Figure 18-3 defined the mode. The UML notation in Figure 18-2 didn’t specify the parameters’ modes. In this case, additional information would be required to know whether a parameter is an input or an output parameter. Distinguish between platform-independent models (PIMs) and platform-specific models (PSMs) The idea is that the generations might pass through different intermediate formats before the final code is generated, and to some extent the source model is more independent from platform details than the destination model of a model transformation.
  4. Describe For Figure 18.5It specifies that a service interface has a name and one or more operations. An operation might consist of some parameters, a return type, and exceptions (which are a special kind of type). Every type at least has a name, but there are some more complicated types: lists (arrays) have multiple values of the same element type, while structures and exceptions have attributes, which in turn have names and types.
  5. Describe For Figure 18.6First, it distinguishes between a service interface and a service implementation, because there might be multiple implementations of a service interface. Each service implementation is provided by a specific system, which has a name and some contact data. In addition, you can define SLAs that are specified as part of the contract between a specific provider and a specific consumer for a specific service implementation.Describe For Figure 18.7At the beginning it is usually enough to have an XML notation for the whole model, from which you generate the corresponding code. Different ways to specify a model can then be transferred into the XML notation. The major benefit of this approach is that it decouples the ways you specify services from transformations to other models and code generation (see Figure 18-7).
  6. Describe For Figure 18.6The three different providers generate only their specific skeletons for the service implementation, and each consumer generates the stubs/proxies it needs. Note In practice there are more things to generate, and that there can be systems that are both providers and consumers. As a consequence, you might even have cyclic dependencies (for example, if system A calls a service at system B and system B calls a service at system A, which might or might not be a logical response)
  7. Note that all of the approaches share an important goal: to minimize and isolate manual modifications as much as possible. That is, when it is possible to split generated and handwritten code into different files, do it. Every such split will enhance maintainability.