Page 1
Basel · Baden · Bern · Lausanne · Zürich · Düsseldorf · Frankfurt/M. · Freiburg i. Br. · Hamburg · München · Stuttgart · Wien
Using Domain Specific Language(s) to Simplify Creating SOA Artifacts
SOA Symposium 2010
Guido Schmutz,Technology Manager / Partner Trivadis AG
5.10.2010, Berlin
Page 2
© 2010Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
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 protected] Blog: http://guidoschmutz.wordpress.com/
Page 3
© 2010
About Trivadis
3
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.
Page 4
© 2010
Agenda
Data are always part of the game.
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
Page 5
© 2010
„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
Page 6
© 2010
„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="http://trivadis.com/service/credit-card/v1" ... name="CreditCardValidation-v1"> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name="validateCardRequest"> <wsdl:part name="request" element="tns:validateCreditCardPaymentRequest"/> </wsdl:message> <wsdl:message name="validateCardResponse"> <wsdl:part name="reply" element="tns:validateCreditCardPaymentResponse"/> </wsdl:message> <wsdl:message name="invalidCreditCardNumberFault"> <wsdl:part name="error„ element="tns:invalidCreditCardNumberFault"/> </wsdl:message> <wsdl:portType name="CreditCardValidationPT"> <wsdl:operation name="validateCard"> <wsdl:input message="tns:validateCardRequest"/> <wsdl:output message="tns:validateCardResponse"/> <wsdl:fault name="InvalidCreditCardNumberFault" message="tns:invalidCreditCardNumberFault"/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...></wsdl:definitions>
<wsdl:definitions xmlns:tns="http://trivadis.com/service/credit-card/v1" ... name="CreditCardValidation-v1"> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name="validateCardRequest"> <wsdl:part name="request" element="tns:validateCreditCardPaymentRequest"/> </wsdl:message> <wsdl:message name="validateCardResponse"> <wsdl:part name="reply" element="tns:validateCreditCardPaymentResponse"/> </wsdl:message> <wsdl:message name="invalidCreditCardNumberFault"> <wsdl:part name="error„ element="tns:invalidCreditCardNumberFault"/> </wsdl:message> <wsdl:portType name="CreditCardValidationPT"> <wsdl:operation name="validateCard"> <wsdl:input message="tns:validateCardRequest"/> <wsdl:output message="tns:validateCardResponse"/> <wsdl:fault name="InvalidCreditCardNumberFault" message="tns:invalidCreditCardNumberFault"/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...></wsdl:definitions>
<xs:schema xmlns:xs=„..." xmlns:tns="http://www.trivadis.com/cdm/credit-card/v1" targetNamespace=„http://www.trivadis.com/cdm/credit-card/v1“ elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> <xs:element name="creditCard" type="tns:CreditCardT"/> <xs:complexType name="CreditCardT"> <xs:sequence> <xs:element name="creditCardKind" type="tns:CreditCardKindT"/> <xs:element name="cardNumber" type="xs:string"/> <xs:element name="cardholderFirstName" type="xs:string" minOccurs="0"/> <xs:element name="cardholderLastName" type="xs:string"/> <xs:element name="expirationMonth" type="tns:MonthT"/> <xs:element name="expirationYear" type="tns:YearT"/> </xs:sequence> <xs:attribute name="id" type="xs:int"/> </xs:complexType> <xs:simpleType name="CreditCardKindT"> <xs:restriction base="xs:string"> <xs:enumeration value="visa"/> <xs:enumeration value="mastercard"/> <xs:enumeration value="amexco"/> </xs:restriction> </xs:simpleType>.../xs:schema>
<xs:schema xmlns:xs=„..." xmlns:tns="http://www.trivadis.com/cdm/credit-card/v1" targetNamespace=„http://www.trivadis.com/cdm/credit-card/v1“ elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> <xs:element name="creditCard" type="tns:CreditCardT"/> <xs:complexType name="CreditCardT"> <xs:sequence> <xs:element name="creditCardKind" type="tns:CreditCardKindT"/> <xs:element name="cardNumber" type="xs:string"/> <xs:element name="cardholderFirstName" type="xs:string" minOccurs="0"/> <xs:element name="cardholderLastName" type="xs:string"/> <xs:element name="expirationMonth" type="tns:MonthT"/> <xs:element name="expirationYear" type="tns:YearT"/> </xs:sequence> <xs:attribute name="id" type="xs:int"/> </xs:complexType> <xs:simpleType name="CreditCardKindT"> <xs:restriction base="xs:string"> <xs:enumeration value="visa"/> <xs:enumeration value="mastercard"/> <xs:enumeration value="amexco"/> </xs:restriction> </xs:simpleType>.../xs:schema>
Page 7
© 2010
Agenda
Data are always part of the game.
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
Page 8
© 2010
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
Page 9
© 2010
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 & EngineeringTM (CBDI-SAETM) Reference Framework.
CBDI-SAE Meta Model for SOA, which is realized via the CBDI-SAE UML Profilefor SOA Which is compliant with
SoaML - for which alsoa SoaML Profile exists.
http://everware-cbdi.com
Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
Page 10
© 2010
«Node»Technology Model::alpha :Sun Serv er
«Node»Technology Model::beta :Sun Server
«Node»Technology Model::r01 :
Router
«executionEnvironment...:EJB Container
(from Technology Model)
«executionEnvironment...:SOAP Engine
(from Technology Model)
«Automation Unit»Implementation Model::
Customers
«Deployed AU»:Customers
«Endpoint»:Customers
«Service Instance»cust01 :Customers
«Service Instance»cust02 :Customers
«instanceOf»
«Deploy»
«Deploy»
«instanceOf»
«Deploy»
«Endpoint Implementation»
«manifest»
«Deploy»
«Communication Path»«Communication Path»
«Business Type»Warehouse
+ name: {id2}+ number: {id1}+ address+ capacity
«Business Type»Vehicle
+ registrationNbr: {id2}+ manufacturer+ model+ capacity+ fleetNbr
«Business Type»Journey
+ date: {id1}+ number: {id1}+ routeCode+ isScheduled
«Business Type»Subcontractor
+ name: {id1}+ address+ performanceRating+ ourAccountNbr
«Business Type»Subcontractor
Location
+ shortName+ address
«Business Type»Shipment
+ tagNbr: {id1}+ destinationAddress+ weight+ dimension+ specialNeeds+ destinationInstructions+ charge+ contentDescription
«Business Type»Pick Up Point
+ shortName: {id1}+ address+ guidance
«Business Type»Invoice
+ number: {id1}+ issueDate+ totalAmount+ status+ discountGiven
«Business Type»Invoice Item
+ number: {id1}+ description+ charge
«Business Type»Account Entry
+ sequenceNbr: {id1}+ amount+ isDebit+ reference+ date
«Business Type»Account
+ number: {id1}+ name+ openingDate+ balance
«Business Type»Payment
+ date: {id1}+ amount: {id1}
«Business Type»Warehouse Position
+ number: {id1}+ description+ typeCode
«Business Type»Customer
+ number: {id1}+ name+ bill ingAddress+ lastYearShipmentsValue+ lastQtrShipmentsValue+ thisQtrShipmentsValue+ contactName1+ contactName2
«Business Type»HazardousShipment
«Business Type»FoodShipment
«Business Type»Handling Procedure
+ parcelType: string+ definition: string+ procedure: string+ constraints: sting
Shipping
Finance
Customer Relations
Suppliers
*
in responseto
0..1
1
is base for
*
1{id1}makes
*
0..1
currentlyconveying
1
1{id1}
holdsshipmentsat*
0..1 currently holds
*
1
paid for by0..1
*
defines procedures for
*
1
origin for
*
0..1
recorded in
1
*
visited on
**
contains
{id1}0..1
recorded in
1
0..1
currentlystores
*
1..*
houses
{id1}
1
requests
1..*
1{id1}
ships from
1..*
1
receives
0..1
1{id1}
makes
*
0..*
owns
1
*
contains
{id1}
CBDI-SAE UML Profile for SOA
Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
Parcels System
«Technical Interface»
Subcontractors
«Technical Interface»
Shipments
«Technical Interface»
Pickup and Deliv er
«Technical Interface»
Warehouses
«Technical Interface»
Customers
«Technical Interface»
Accounts
«Technical Interface»
Inv oices
«Technical Interface»
AddressFormatter
«Technical Interface»
Inv oicing
«Technical Interface»
Transactions
«Technical Interface»
New Accounts
Application
Process
Core Business
Utility
Underlying
«Automation Unit»Pickup and Deliv er
«Automation Unit»Shipping Objects
«Automation Unit»Inv oices
«Automation Unit»Customers
«Automation Unit»Accounts
«Automation Unit»Prov iderX
«Automation Unit»Customer
Relationships«Automation Unit»
Accounting System
«Automation U...Schedule Pickup
«Technical Interface»
Schedule Pickup
«Automation U...Obtain Payment
«Technical Interface»
Obtain Payment
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
«Required Behavior»
Business Type ModelShowing Domains
Service Implementation ArchitectureShowing Services and Automation Units
Service Deloyment ArchitectureShowing Deployments
http://everware-cbdi.com
Page 11
© 2010
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/
Page 12
© 2010
SoaML
Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
Page 13
© 2010
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
Page 14
© 2010
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
Page 15
© 2010
But wouldn't it be easier .... use a DSL for WSDL
Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
Import common.msgtypenamespace 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
}
<wsdl:definitions xmlns:tns="http://trivadis.com/service/credit-card/v1"
... name="CreditCardValidation-v1"> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name="validateCardRequest"> <wsdl:part name="request" element="tns:validateCreditCardPaymentRequest"/> </wsdl:message> <wsdl:message name="validateCardResponse"> <wsdl:part name="reply" element="tns:validateCreditCardPaymentResponse"/> </wsdl:message> <wsdl:message name="invalidCreditCardNumberFault"> <wsdl:part name="error„ element="tns:invalidCreditCardNumberFault"/> </wsdl:message> <wsdl:portType name="CreditCardValidationPT"> <wsdl:operation name="validateCard"> <wsdl:input message="tns:validateCardRequest"/> <wsdl:output message="tns:validateCardResponse"/> <wsdl:fault name="InvalidCreditCardNumberFault" message="tns:invalidCreditCardNumberFault"/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...></wsdl:definitions>
<wsdl:definitions xmlns:tns="http://trivadis.com/service/credit-card/v1"
... name="CreditCardValidation-v1"> <wsdl:types> <xsd:schema ...> </wsdl:types> <wsdl:message name="validateCardRequest"> <wsdl:part name="request" element="tns:validateCreditCardPaymentRequest"/> </wsdl:message> <wsdl:message name="validateCardResponse"> <wsdl:part name="reply" element="tns:validateCreditCardPaymentResponse"/> </wsdl:message> <wsdl:message name="invalidCreditCardNumberFault"> <wsdl:part name="error„ element="tns:invalidCreditCardNumberFault"/> </wsdl:message> <wsdl:portType name="CreditCardValidationPT"> <wsdl:operation name="validateCard"> <wsdl:input message="tns:validateCardRequest"/> <wsdl:output message="tns:validateCardResponse"/> <wsdl:fault name="InvalidCreditCardNumberFault" message="tns:invalidCreditCardNumberFault"/> </wsdl:operation> </wsdl:portType> <wsdl:binding ...> <wsdl:service ...></wsdl:definitions>
abstract message common {requestNr : String [1:1]
}
abstract message common {requestNr : String [1:1]
}
Page 16
© 2010
... and for the XSD‘s ....
Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
namespace cdm.credit-card(1.0)
entity CreditCard {id : IntegercreditCardKind : CreditCardKind [1:1]cardNumber : String [1:1]cardholderFirstName : StringcardholderLastName : String [1:1]expirationMonth : Month [1:1]expirationYear : Year [1:1]
}
dataType Month extends Integer pattern "[0-1][0-9]"
dataType Year extends Integer pattern "[0-9][0-9][0-9][0-9]"
dataType CrediCardKind extends String enum { "visa", "mastercard", "amexco" }
namespace cdm.credit-card(1.0)
entity CreditCard {id : IntegercreditCardKind : CreditCardKind [1:1]cardNumber : String [1:1]cardholderFirstName : StringcardholderLastName : String [1:1]expirationMonth : Month [1:1]expirationYear : Year [1:1]
}
dataType Month extends Integer pattern "[0-1][0-9]"
dataType Year extends Integer pattern "[0-9][0-9][0-9][0-9]"
dataType CrediCardKind extends String enum { "visa", "mastercard", "amexco" }
<xs:schema xmlns:xs=„..." xmlns:tns="http://www.trivadis.com/cdm/credit-card/v1" targetNamespace=„http://www.trivadis.com/cdm/credit-card/v1“ elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> <xs:element name="creditCard" type="tns:CreditCardT"/> <xs:complexType name="CreditCardT"> <xs:sequence> <xs:element name="creditCardKind" type="tns:CreditCardKindT"/> <xs:element name="cardNumber" type="xs:string"/> <xs:element name="cardholderFirstName" type="xs:string" minOccurs="0"/> <xs:element name="cardholderLastName" type="xs:string"/> <xs:element name="expirationMonth" type="tns:MonthT"/> <xs:element name="expirationYear" type="tns:YearT"/> </xs:sequence> <xs:attribute name="id" type="xs:int"/> </xs:complexType> <xs:simpleType name="CreditCardKindT"> <xs:restriction base="xs:string"> <xs:enumeration value="visa"/> <xs:enumeration value="mastercard"/> <xs:enumeration value="amexco"/> </xs:restriction> </xs:simpleType>.../xs:schema>
<xs:schema xmlns:xs=„..." xmlns:tns="http://www.trivadis.com/cdm/credit-card/v1" targetNamespace=„http://www.trivadis.com/cdm/credit-card/v1“ elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> <xs:element name="creditCard" type="tns:CreditCardT"/> <xs:complexType name="CreditCardT"> <xs:sequence> <xs:element name="creditCardKind" type="tns:CreditCardKindT"/> <xs:element name="cardNumber" type="xs:string"/> <xs:element name="cardholderFirstName" type="xs:string" minOccurs="0"/> <xs:element name="cardholderLastName" type="xs:string"/> <xs:element name="expirationMonth" type="tns:MonthT"/> <xs:element name="expirationYear" type="tns:YearT"/> </xs:sequence> <xs:attribute name="id" type="xs:int"/> </xs:complexType> <xs:simpleType name="CreditCardKindT"> <xs:restriction base="xs:string"> <xs:enumeration value="visa"/> <xs:enumeration value="mastercard"/> <xs:enumeration value="amexco"/> </xs:restriction> </xs:simpleType>.../xs:schema>
Page 17
© 2010
Agenda
Data are always part of the game.
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
Page 18
© 2010
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
Page 19
© 2010
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("A") .processor().cores(2).i386() .disk().size(150) .disk().size(75).speed(7200).sata() .end();
computer("A") .processor().cores(2).i386() .disk().size(150) .disk().size(75).speed(7200).sata() .end();
computer A { processor i386 with 2 cores disks {
size 150size 75 speed 7200 type sata
}
computer A { processor i386 with 2 cores disks {
size 150size 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);
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);
Page 20
© 2010
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
Page 21
© 2010
Agenda
Data are always part of the game.
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
Page 22
© 2010
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
Page 23
© 2010
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
Page 24
© 2010
Xtext in Action
1. Create an Xtext Project
2. Build the Grammar
3. Generate the Language Artefacts
4. Run the Generated IDE Plug-in
5. Write a Code Generator
Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
DSL to be supported
Page 25
© 2010
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
Page 26
© 2010
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
Page 27
© 2010
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 sequenceof 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)*;DomainModel : (elements+=AbstractElement)*;
AbstractElement: PackageDeclaration | Type;AbstractElement: PackageDeclaration | Type;
TypeRef: referenced=[Type] (multi?='*')?;TypeRef: referenced=[Type] (multi?='*')?;
QualifiedName: ID (‚.‘ ID)*;QualifiedName: ID (‚.‘ ID)*;
Page 28
© 2010
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
Page 29
© 2010
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
Page 30
© 2010
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
Page 31
© 2010
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
Page 32
© 2010
Xtext in Action – 5. Write a Code Generator
Result generated
Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
Page 33
© 2010
Agenda
Data are always part of the game.
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
Page 34
© 2010
Service DSL Prototype
Grammar
DSL in action
Using Domain Specific Language (s) to Simplify Creating SOA Artifacts
Page 35
© 2010
Agenda
Data are always part of the game.
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
Page 36
© 2010
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
Page 37
Basel · Baden · Bern · Lausanne · Zürich · Düsseldorf · Frankfurt/M. · Freiburg i. Br. · Hamburg · München · Stuttgart · Wien
Thank you!
SOA Symposium 2010
Guido Schmutz,Technology Manager / Partner Trivadis AG
5.10.2010, Berlin