• Save
Dsl for-soa-artefacts
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Dsl for-soa-artefacts

on

  • 1,592 views

The presentation shows a first version of a Domain Specific Language (DSL) based on Eclipse XText, the tooling provided with it and the way to generate the necessary XSD and WSDL artifacts.

The presentation shows a first version of a Domain Specific Language (DSL) based on Eclipse XText, the tooling provided with it and the way to generate the necessary XSD and WSDL artifacts.

Statistics

Views

Total Views
1,592
Views on SlideShare
1,584
Embed Views
8

Actions

Likes
1
Downloads
0
Comments
0

2 Embeds 8

http://www.linkedin.com 6
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Hier könnte eine Kopfzeile stehen 06.10.10 Hier könnte eine Fusszeile stehen Ihr müsst nicht alle Punkt aufzählen. Vielleicht der Hinweis, CH-Unternehmen mit 13 Standorten in D-A-CH, Anzahl Mitarbeiter und das wir finanziell unabhängig sind.

Dsl for-soa-artefacts Presentation Transcript

  • 1. Using Domain Specific Language(s) to Simplify Creating SOA Artifacts SOA Symposium 2010 Guido Schmutz, Technology Manager / Partner Trivadis AG 5.10.2010, Berlin
  • 2. Introduction
    • Guido Schmutz
      • Working for Trivadis for more than 13 years
        • leading and independent IT service company operating in Germany, Austria and Switzerland
      • Oracle ACE Director for Fusion Middleware and SOA
      • Co-Author of different books
      • Consultant, Trainer Software Architect for Java, Oracle, SOA and EDA
      • More than 20 years of software development experience
      • Contact: [email_address]
      • Blog: http://guidoschmutz.wordpress.com/
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 3. About Trivadis
    • Swiss IT consulting company
      • 13 locations in Switzerland, Germany and Austria
      • ~ 540 employees
    • Key figures 2009
      • Services for more than 650 clients in over 1'600 projects
      • Over 150 service level agreements
      • More than 5'000 training participants
      • Research and development budget: CHF 6.0 Mio. / EUR 3.6 Mio.
  • 4. Agenda
    • Introduction
    • Alternative ways to design service contract
    • Domain Specific Languages (DSL)
    • Eclipse Xtext
    • Prototype Implementations
    • Summary
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts Data are always part of the game.
  • 5. „ Problem“
    • Most SOA platforms do not make a contract-first service design easy
      • Creation of WSDL and XSD is too much effort
    • There is build-in support in the IDE to graphically implement WSDL and XSD
      • Platform specific, no standard for look-and-feel
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 6. „ Problem“
    • Lot of repetition
      • Very talkative
      • More options than (often) necessary => RPC/literal
    • How to ensure Design guidelines
      • WS-I compliance
      • Asynchronous Interface
      • Service versioning
    • Ensure naming conventions
      • Name of messages
      • Name of port types
      • Name of bindings
    • So what are the other options?
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts <wsdl:definitions xmlns:tns=&quot;http://trivadis.com/service/credit-card/v1&quot; ... name=&quot;CreditCardValidation-v1&quot;> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name=&quot;validateCardRequest&quot;> <wsdl:part name=&quot;request&quot; element=&quot;tns:validateCreditCardPaymentRequest&quot;/> </wsdl:message> <wsdl:message name=&quot;validateCardResponse&quot;> <wsdl:part name=&quot;reply&quot; element=&quot;tns:validateCreditCardPaymentResponse&quot;/> </wsdl:message> <wsdl:message name=&quot;invalidCreditCardNumberFault&quot;> <wsdl:part name=&quot;error„ element=&quot;tns:invalidCreditCardNumberFault&quot;/> </wsdl:message> <wsdl:portType name=&quot;CreditCardValidationPT&quot;> <wsdl:operation name=&quot;validateCard&quot;> <wsdl:input message=&quot;tns:validateCardRequest&quot;/> <wsdl:output message=&quot;tns:validateCardResponse&quot;/> <wsdl:fault name=&quot;InvalidCreditCardNumberFault&quot; message=&quot;tns:invalidCreditCardNumberFault&quot;/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...> </wsdl:definitions> <xs:schema xmlns:xs=„...&quot; xmlns:tns=&quot;http://www.trivadis.com/cdm/credit-card/v1&quot; targetNamespace= „http://www.trivadis.com/cdm/credit-card/v1 “ elementFormDefault=&quot;qualified&quot; attributeFormDefault=&quot;unqualified&quot; version=&quot;1.0&quot;> <xs:element name=&quot;creditCard&quot; type=&quot;tns:CreditCardT&quot;/> <xs:complexType name=&quot;CreditCardT&quot;> <xs:sequence> <xs:element name=&quot;creditCardKind&quot; type=&quot;tns:CreditCardKindT&quot;/> <xs:element name=&quot;cardNumber&quot; type=&quot;xs:string&quot;/> <xs:element name=&quot;cardholderFirstName&quot; type=&quot;xs:string&quot; minOccurs=&quot;0&quot;/> <xs:element name=&quot;cardholderLastName&quot; type=&quot;xs:string&quot;/> <xs:element name=&quot;expirationMonth&quot; type=&quot;tns:MonthT&quot;/> <xs:element name=&quot;expirationYear&quot; type=&quot;tns:YearT&quot;/> </xs:sequence> <xs:attribute name=&quot;id&quot; type=&quot;xs:int&quot;/> </xs:complexType> <xs:simpleType name=&quot;CreditCardKindT&quot;> <xs:restriction base=&quot;xs:string&quot;> <xs:enumeration value=&quot;visa&quot;/> <xs:enumeration value=&quot;mastercard&quot;/> <xs:enumeration value=&quot;amexco&quot;/> </xs:restriction> </xs:simpleType> ... /xs:schema>
  • 7. Agenda
    • Introduction
    • Alternative ways to design service contract
    • Domain Specific Languages (DSL)
    • Eclipse Xtext
    • Prototype Implementations
    • Summary
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts Data are always part of the game.
  • 8. WSDL and XSD UML Profile in UML Tools
    • Enterprise Architect has a special profile for WSDL and XSD modelling
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 9. CBDI-SAE Meta Model for SOA
    • The CBDI-SAE Meta Model for SOA is a 'class model' of the concepts contained in the CBDI Service Architecture & Engineering TM (CBDI-SAE TM ) Reference Framework. 
    • CBDI-SAE Meta Model for SOA, which is realized via the CBDI-SAE UML Profile for SOA
      • Which is compliant with SoaML -  for which also a SoaML Profile exists.
    • http://everware-cbdi.com
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 10. CBDI-SAE UML Profile for SOA Using Domain Specific Language (s) to Simplify Creating SOA Artifacts Business Type Model Showing Domains Service Implementation Architecture Showing Services and Automation Units Service Deloyment Architecture Showing Deployments http://everware-cbdi.com
  • 11. SoaML
    • An OMG Standard for Modeling Service Oriented Architectures
      • Adopted from the UML ® Profile for Modeling Services (UPMS) RFP
      • Used for modeling SOA at the business, enterprise and technology levels
      • Leverages Model Driven Architecture
    • A “Profile” of the Unified Modeling Language™
      • Can be used with off-the-shelf UML tools as well as customized tooling
    • In the “finalization” stage of the OMG process – essentially an adopted “beta” specification
      • Finalization with minor clean-up expected to complete this year
    • Tool support & implementations already exist
      • Tool support – making it easy to create services models
      • MDA Implementations – provisioning web services, business artifacts and implementations from SoaML models
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts 1.0-Beta-2 available: http://www.omg.org/spec/SoaML/
  • 12. SoaML - Goals
    • Intuitive and complete support for modeling services in UML
    • Support for bi-directional asynchronous services between multiple parties
    • Support for Services Architectures where parties provide and use multiple services.
    • Easily mapped to and made part of a business process specification
    • Compatibility with UML, BPDM and BPMN for business processes
    • Direct mapping to web services
    • Top-down, bottom up or meet-in-the-middle modeling
    • Design by contract or dynamic adaptation of services
    • To specify and relate the service capability and its contract
    • No changes to UML
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 13. SoaML Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 14. MDA vs. MDSD
    • MDA = Model Driven Architecture
      • 100% generation
      • Standardized by the OMG since 1999
      • Based on XMI, MOC, OCL, UML...
      • Aims at automating all transformations between models to code , suppressing the coding part
      • Driven by CIMs, PIMs, PSMs and PDMs
      • Tries to define standard meta-models shared across industry domains
    • MDSD = Model Driven Software Development
      • Based on the ideas brought by MDA
      • Not bound to its standards
        • can be any meta-model like DSLs, not only UML and profiles
      • Try to promote customized DSLs, not assuming that every body will have the same needs on a given domain
      • Use models as abstraction and still leave a place for development tasks
      • Defines its own ideas of PIMs and PDMs depending on projects or needs contexts
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 15. MDA vs. MDSD
    • MDA standard is more something made for the big players in the industry
    • MDSD is a more flexible approach that can be used by a larger group of users, less attached to standards and with smaller scale needs.
    • MDSD is a pragmatic way of using MDA concepts
    • MDSD is more lightweight than MDA
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 16. But wouldn't it be easier .... use a DSL for WSDL Using Domain Specific Language (s) to Simplify Creating SOA Artifacts <wsdl:definitions xmlns:tns=&quot;http://trivadis.com/service/credit-card/v1&quot; ... name=&quot;CreditCardValidation-v1&quot;> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name=&quot;validateCardRequest&quot;> <wsdl:part name=&quot;request&quot; element=&quot;tns:validateCreditCardPaymentRequest&quot;/> </wsdl:message> <wsdl:message name=&quot;validateCardResponse&quot;> <wsdl:part name=&quot;reply&quot; element=&quot;tns:validateCreditCardPaymentResponse&quot;/> </wsdl:message> <wsdl:message name=&quot;invalidCreditCardNumberFault&quot;> <wsdl:part name=&quot;error„ element=&quot;tns:invalidCreditCardNumberFault&quot;/> </wsdl:message> <wsdl:portType name=&quot;CreditCardValidationPT&quot;> <wsdl:operation name=&quot;validateCard&quot;> <wsdl:input message=&quot;tns:validateCardRequest&quot;/> <wsdl:output message=&quot;tns:validateCardResponse&quot;/> <wsdl:fault name=&quot;InvalidCreditCardNumberFault&quot; message=&quot;tns:invalidCreditCardNumberFault&quot;/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...> </wsdl:definitions> abstract message common { requestNr : String [1:1] } Import common.msgtype namespace service.credit-card(1.0) using cdm.credit-card(1.0) as cc message validateCardRequest extends common { creditCard : cc.CreditCard forAmount : Double } message validateCardResponse { requestNr : String[1:1] reservationNumber : String } fault invalidCreditCardNumber { code : String creditCard : cc.CreditCard } service CreditCardValidation { sync operation validateCard throws invalidCreditCardNumber input validateCardRequest output validateCardResponse }
  • 17. ... and for the XSD‘s .... Using Domain Specific Language (s) to Simplify Creating SOA Artifacts namespace cdm.credit-card(1.0) entity CreditCard { id : Integer creditCardKind : CreditCardKind [1:1] cardNumber : String [1:1] cardholderFirstName : String cardholderLastName : String [1:1] expirationMonth : Month [1:1] expirationYear : Year [1:1] } dataType Month extends Integer pattern &quot;[0-1][0-9]&quot; dataType Year extends Integer pattern &quot;[0-9][0-9][0-9][0-9]&quot; dataType CrediCardKind extends String enum { &quot;visa&quot;, &quot;mastercard&quot;, &quot;amexco&quot; } <xs:schema xmlns:xs=„...&quot; xmlns:tns=&quot;http://www.trivadis.com/cdm/credit-card/v1&quot; targetNamespace= „http://www.trivadis.com/cdm/credit-card/v1 “ elementFormDefault=&quot;qualified&quot; attributeFormDefault=&quot;unqualified&quot; version=&quot;1.0&quot;> <xs:element name=&quot;creditCard&quot; type=&quot;tns:CreditCardT&quot;/> <xs:complexType name=&quot;CreditCardT&quot;> <xs:sequence> <xs:element name=&quot;creditCardKind&quot; type=&quot;tns:CreditCardKindT&quot;/> <xs:element name=&quot;cardNumber&quot; type=&quot;xs:string&quot;/> <xs:element name=&quot;cardholderFirstName&quot; type=&quot;xs:string&quot; minOccurs=&quot;0&quot;/> <xs:element name=&quot;cardholderLastName&quot; type=&quot;xs:string&quot;/> <xs:element name=&quot;expirationMonth&quot; type=&quot;tns:MonthT&quot;/> <xs:element name=&quot;expirationYear&quot; type=&quot;tns:YearT&quot;/> </xs:sequence> <xs:attribute name=&quot;id&quot; type=&quot;xs:int&quot;/> </xs:complexType> <xs:simpleType name=&quot;CreditCardKindT&quot;> <xs:restriction base=&quot;xs:string&quot;> <xs:enumeration value=&quot;visa&quot;/> <xs:enumeration value=&quot;mastercard&quot;/> <xs:enumeration value=&quot;amexco&quot;/> </xs:restriction> </xs:simpleType> ... /xs:schema>
  • 18. Agenda
    • Introduction
    • Alternative ways to design service contract
    • Domain Specific Languages (DSL)
    • Eclipse Xtext
    • Prototype Implementations
    • Summary
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts Data are always part of the game.
  • 19. Domain Specific Language (DSL)
    • A Domain Specific Language (DSL) is
      • A small programming language, which focuses on a particular domain
      • The right tool for the right job
    • The opposite is a General Purpose Language (GPL)
      • A language such as Java or C#
      • A general purpose modeling language such as UML
    • A DSL can be a visual diagramming, programatic abstractions or textual languages
      • Text based DSL are more and more common
    • Examples of existing DSL‘s
      • SQL, Ant, XML, BPEL, BPMN
    • Define you own custom DSL according to the problem
      • Service interface in our case
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 20. Internal vs. External DSL
    • Internal DSL
      • The easiest form to write a DSL
      • No need for grammer and language parsing
      • Use regular language environment
        • So any experssion must be a legal expression in the host language
        • Influenced by Ruby, Groovy ....
      • API's designed that expression look like DSL
        • Fluent language, Method chaining
    • External DSL
      • analogous to creating a general purpose programming language
      • Needs a formal grammar
      • Often has a text format, but can be visual (graphical) as well
      • parsing process operates on pure text input which is not constrained by any particular language
      • Not immediately executable
        • either an interpreter or generator is used
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts computer(&quot;A&quot;) .processor().cores(2).i386() .disk().size(150) .disk().size(75).speed(7200).sata() .end(); computer A { processor i386 with 2 cores disks { size 150 size 75 speed 7200 type sata } Processor p = new Processor(2, Processor.Type.i386); Disk d1 = new Disk(150, Disk.UNKNOWN_SIZE, null); Disk d2 = new Disk(75, 7200, Disk.Interface.SATA); return new Computer(p, d1, d2);
  • 21. Domain Specific Language (DSL)
    • Advantages
      • allow solutions to be expressed at the level of abstraction of the problem domain
        • so that domain experts themselves can understand, validate, modify, and often even develop DSL programs
      • Self-documenting code
      • DSL enhance quality, productivity, reliability, maintainability, portability and reusability
      • DSL allow validation at the domain level
    • Disadvantages
      • Cost of learning a new language vs. its limited applicability
      • Cost of designing, implementing, and maintaining a DSL as well as the tools required to develop with it (IDE)
      • Finding, setting, and maintaining proper scope
      • Difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs
      • Potential loss of processor efficiency compared with hand-coded software
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 22. Agenda
    • Introduction
    • Alternative ways to design service contract
    • Domain Specific Languages (DSL)
    • Eclipse Xtext
    • Prototype Implementations
    • Summary
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts Data are always part of the game.
  • 23. What is Eclipse Xtext
    • Language Development Framework / Domain Specific Language Framework
    • Based on
      • Eclipse Modeling Framework (EMF)
      • ANTLR Parser Generator
      • Google Guice
    • Xtext is a professional Open-Source project
      • the main developers and the project lead, work for itemis, a well known consulting company specialized on model-based development
      • Xtext is an Eclipse.org project
        • no IP issues, because the Eclipse Foundation has their own lawyers who take care that no intellectual property is violated.
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 24. Highlights of Xtext
    • Xtext – Language Development Framework
    • Syntax Highlighting
    • Code Completion
    • Validation and Quick Fixes
    • More Editor Features
    • Advanced Workbench Integration
    • Integration with EMF
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 25. Xtext in Action
    • Create an Xtext Project
    • Build the Grammar
    • Generate the Language Artefacts
    • Run the Generated IDE Plug-in
    • Write a Code Generator
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts DSL to be supported
  • 26. Xtext in Action – 1. Create an Xtext Project
    • Use the Xtext wizard to create a new project:
      • File -> New -> Project... -> Xtext -> Xtext project
    • Keep “Create generator project” checked
      • we will use the code generator in a second step
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 27. Xtext in Action – 2. Build the Grammer
    • Grammar has two purposes
      • describes the concrete syntax of text files that can be processed by the tools of your new DSL
      • equates the meta level, i.e. the model which describes your model
    • A Grammar as a unique name
    • Terminal rules / Parser rules
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 28. Xtext in Action – 2. Build the Grammer
    • The DomainModel consists of elements
    • An AbstractElement can either be a PackageDeclaration or a Type
    • Boolean assignment operator ?=
    • A QualifiedName is a sequence of IDs and dots
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts (no operator) exactly one ? zero or one * zero or more + one or more feature=... corresponds to setFeature(...) list+=... corresponds to getList().add(...) condition?=... corresponds to setCondition(true) DomainModel : (elements+=AbstractElement)*; AbstractElement: PackageDeclaration | Type; TypeRef: referenced=[Type] (multi?='*')?; QualifiedName: ID (‚.‘ ID)*;
  • 29. Xtext in Action – 3. Generate Language Artefacts
    • Now we need to run the generator that will derive the various language components.
      • locate the file GenerateXtextDemo.mwe2 file next to the grammar file in the package explorer view
      • from its context menu, choose Run As -> MWE2 Workflow
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 30. Xtext in Action – 4. Run the Generated IDE Plug-in
    • Right-click on the Xtext project and choose Run As -> Eclipse Application
    • In new workbench, create a new project ( File -> New -> Project... -> General -> Project) and therein a new file with the file extension you chose in the beginning ( *.xtextdemo).
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 31. Xtext in Action – 5. Write a Code Generator
    • We checked the option Create a generator project in the wizard, which as a result created a third project for us in the workspace
    • First let's change the workflow to call the template for Entity's
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 32. Xtext in Action – 5. Write a Code Generator
    • Using Xpand and Xtend for Code generation
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 33. Xtext in Action – 5. Write a Code Generator
    • Result generated
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 34. Agenda
    • Introduction
    • Alternative ways to design service contract
    • Domain Specific Languages (DSL)
    • Eclipse Xtext
    • Prototype Implementation
    • Summary
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts Data are always part of the game.
  • 35. Service DSL Prototype
    • Grammar
    • DSL in action
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 36. Agenda
    • Introduction
    • Alternative ways to design service contract
    • Domain Specific Languages (DSL)
    • Eclipse Xtext
    • Prototype Implementation
    • Summary
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts Data are always part of the game.
  • 37. Summary
    • DSL can help to simplify creation of XSD’s and WSDL
    • Eclipse Xtext offers very strong support for implementing DSL
    • First prototype of DSL and Generator for WSDL and XSD is ready
      • Still in proof-of-concept stage
      • Grammar needs to be revised
      • Some grammar and code refactoring necessary
      • Advanced IDE functionalities like Quick Fix, Formatting, Templates have not yet been used
      • Will be extended to generate more artifacts of a given SOA platform
        • i.e. Oracle Service Bus (OSB) proxy services handling service versioning
        • Support Testing
        • Add governance information (consumer + producer information, service classification, domain, ownership, SLA, …)
    Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
  • 38. Thank you! SOA Symposium 2010 Guido Schmutz, Technology Manager / Partner Trivadis AG 5.10.2010, Berlin