Dsl for Soa Artefacts

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

© 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/

© 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.

© 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

© 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


© 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?


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


© 2010

Agenda


Introduction



Eclipse Xtext


Summary


© 2010

WSDL and XSD UML Profile in UML Tools

Enterprise Architect has a special profile for WSDL and XSD modelling


© 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


© 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


Parcels System

«Technical Interface»

Subcontractors


Shipments


Pickup and Deliv er


Warehouses


Customers


Accounts


Inv oices


AddressFormatter


Inv oicing


Transactions


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


Schedule Pickup

«Automation U...Obtain Payment


Obtain Payment

«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

© 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


1.0-Beta-2 available: http://www.omg.org/spec/SoaML/

© 2010

SoaML


© 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


© 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


© 2010

But wouldn't it be easier .... use a DSL for WSDL


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]

}

© 2010

... and for the XSD‘s ....


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" }



© 2010

Agenda


Introduction



Eclipse Xtext


Summary


© 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


© 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


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);

© 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


© 2010

Agenda


Introduction



Eclipse Xtext


Summary


© 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.


© 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


© 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


DSL to be supported

© 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


© 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


© 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


(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)*;

© 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


© 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).


© 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


© 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, …)


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

Dsl for Soa Artefacts

Documents

Transcript of Dsl for Soa Artefacts