4-1

1ICT

INF5120 – Model-Based System Development

Lecture #4: Language Engineering and DSL – SOA Example

11 February 2008Brian Elvesæter, SINTEF ICT

2ICT

Outline

UML profilesDomain-specific languages (DSLs)Service-oriented architecture (SOA)SOA reference modelsUML Profile and Metamodel for Services (UPMS)References

4-2

3ICT

UML profiles

4ICT

UML profiles

They allow us to adapt the UML language to the needs of the analysts or the application domainAllows designers to model using application domain concepts.There are three extension mechanisms:

StereotypesRestrictionsTagged values

4-3

5ICT

Stereotype

Extends the vocabulary of UML with new construction elementsderived from existing UML but specific to a problem domain

Can have associated restrictions and tagged valuesPossibility of assigning an icon for a better graphical representation

DB Partners

6ICT

Restriction

Is a semantical condition represented by a textual expressionImposes some kind of condition or requisite on the element to which it is appliedOCL – Object Constraint Language

{An interface does not have attributes, only operations}

4-4

7ICT

Tagged value

Is a property associated to a model elementUsed to store information about the element

Management information, documentation, coding parameters, ...

Generally, the tools store this information but it is not shown in the diagrams

8ICT

Metamodels and profiles

MOF

UML process genericMeta-model

real-timemodel

WorkflowMeta-model

UMLFor J2EE

migrationmodel

Workflowmodel

Migration orientedprocess Meta-model

UMLReal-time

M3

M2

M1

extension

relationship

model <-> meta-model

relationship

4-5

9ICT

Classification

Dog

Collie

Animal

LivingBeing Four Legged

Object

Celebrity

MovieStar

Lassie

10ICT

Classification dimensions

Collie

Celebrity

Four Legged Object

Animal

Dog

Movie Star

Model Element

Instance

Object

Ontological classification(domain types)

Linguistic classification(representation form)

4-6

11ICT

Kinds of metamodels

Two kinds of information of a set of models are modelled in metamodels

Form (linguistic aspects)OMG is predominantly occupied with this

Content (ontological aspects)

12ICT

Linguistic metamodelling

LassieCollie

Class Object

Class

represents represents

linguistic ”instance-of” linguistic ”instance-of”

linguistic ”instance-of” linguistic ”instance-of”

instance-of

ontological instance-of

ontological instance-of

L0 (called M0 in OMG)

L1 (called M1 in OMG)

L2 (called M2 in OMG)

L3 (called M3 in OMG)

4-7

13ICT

Ontological metamodelling

Lassie

Collie Class

Breed

represents linguistic instance-ofO0

O1

O2

O3

Object

Biological rank

ontological ”instance-of”

linguistic instance-of

linguistic instance-ofontological ”instance-of”

ontological ”instance-of”

ontological ”instance-of”

L1 L2

14ICT

Domain-specific languages (DSLs)

4-8

15ICT

UML – one size fits all?

While the OMG MDA promotes UML as the visual “universal” glue suitable for modelling everything, we are also seeing a trend towards development and co-existence of several domain-specific modelling languages, e.g. supported by the Microsoft Domain-Specific Language (DSL) tools (http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx).Such approaches are now also being discussed in various OMG forums.UML is seen as a “general-purpose” language while DSLs may be more expressive for most purposes.A model-driven framework needs to acknowledge the existence of differentmodels and views expressed in different modelling languages.The MDA technologies can help us to align these models through a common metamodelling language on which model transformations and model mappings can be defined.

16ICT

Software factory

The Software Factories Web site (http://www.softwarefactories.com/) defines the term Software Factory in the following way:“A Software Factory is a software product line that configures extensible development tools like Visual Studio Team System with packaged content like DSLs, patterns, frameworks and guidance, based on recipes for building specific kinds of applications. For example, we might set up a Software Factory for thin client Customer Relationship Management (CRM) applications using the .NET framework, C#, the Microsoft Business Framework, Microsoft SQL Server, and the Microsoft Host Integration Server. Equipped with this factory, we could rapidly punch out an endless variety of CRM applications, each containing unique features based on the unique requirements of specific customers. Better yet, we could use this factory to create an ecosystem, by making it available to third parties, who could extend it to rapidly build CRM applications incorporating their value added extensions.”

4-9

17ICT

UML and DSLs

The issue of the role of UML is often stated in overly simplistic terms: MDD advocates the use of UML for all domain modelling while the Software Factories approach advocates that UML never used.This is an incorrect statement of the positions of both camps.

While the MDD approach treats UML, with customization, as the modelling language of choice for most application modelling, it also acknowledges the value of custom languages in certain specialized circumstances.This is the purpose of the OMG Meta-Object Facility (MOF) standard that plays an important role in MDD. UML itself is defined using MOF and there are MOF definitions of many other languages.The MDD approach acknowledges the value of non-UML DSLs as a technique to be applied judiciously.Further, the Software Factories approach does not reject UML entirely. It suggests that you use UML for developing sketches and documentation, where DSLs should be used for developing models from which code is generated.

18ICT

Advantages of using UML profiles

UML is an open standard modelling language for which there are many available books and training courses.UML profiles provide a lightweight approach that is easily implemented using readily available UML tooling.Models with UML profiles applied can be read by all UML tools even if they do not have any knowledge of the profile.Basing all DSLs on UML creates a set of related languages that share common concepts.UML can be used for high-level architectural models as well as detailed models from which code can be generated.

4-10

19ICT

Disadvantages of using UML profiles

UML profiles only permit a limited amount of customization.

It is not possible to introduce new modelling concepts that cannot be expressed by extending existing UML elements.

The use of UML does require familiarity with modelling concepts.

20ICT

Service-oriented architecture (SOA)

4-11

21ICT

SOA definition

Service-oriented architecture (SOA)

“A set of components which can be invoked, and whose interface descriptions can be published, discovered and invoked over a network.” (W3C)

http://www.w3.org/

22ICT

Architectural style

Service-oriented architecture (SOA)architectural paradigm for organizing and utilizingdistributed system capabilities that may be under the control of different ownership domains.

Evolution of architectural styles to designing software systems

Data-orientationProcedure-orientationObject-orientationComponent- and message-orientationService-orientation

4-12

23ICT

How is SOA different (1)

Object-orientation (OO) vs. service-orientation (SO)Focus

OO: Focuses on packaging data with operations.SO: Focuses on the task or business function – getting something done.

MethodOO: Intentional melding of methods to a given data object, where methods are a property of the object.SO: Services represents access to methods, but the actual existence of methods and any connection to objects is incidental.

UsageOO: To use an object, it must first be instantiated.SO: One interacts with a service where it exists.

SemanticsOO: An object exposes structure but there is no way to express semantics other than what can be captured as comments in the class definition.SO: SOA emphasizes the need for clear semantics.

24ICT

How is SOA different (2)

Organizing and understanding information communication technology (ICT)

SOA reflects the reality that ownership boundaries are a motivating consideration in the architecture and design of systems.SOA applies the lessons learned from commerce to the organization of ICT assets to facilitate the matching of capabilities and needs.

Two or more entities come together within the context of a single interaction implies the exchange of some type of value.Evolve away from interactions defined in a point-to-point manner to a marketplace of services.

4-13

25ICT

SOA concepts

Key conceptsServiceHigh interoperabilityLoose coupling

SOA is not a specific technology

26ICT

Service

IT representation of business functionality

Implemented via (multiple messages) thatreturn information and/orchange the state of an associated entity

Syntactically described with a (service) interface

Semantically described using (service) contracts

4-14

27ICT

Service properties

Self-containedindependent, autonomous

Course-grainedone call to change multiple attributes instead of a call for each attribute

Visible/discoverablemechanisms to find the right service

Statelessresults/effects don’t depend on previous calls

Idempotentmultiple identical calls have one effect

Reusabledesigned to be used by multiple consumers

ComposableCoordination and assembling of collection of services

Non-functional attributesSLAs (Service-Level Agreements)QoS (Quality of Service)…

28ICT

Large distributed systems

Key characteristicsLegacy, legacy, legacyCan’t start from scratchHighly heterogeneousLong lifetime of business data and contentsLarge companies with political environmentsBottlenecks are suicide (technical and organizational)Perfectionism is to expensive

Key requirementsScalabilityFlexibilityFault tolerance

4-15

29ICT

Forms of loose coupling

asynchronoussynchronousDeployment

compensation2PC (two-phase commit)Transactionally

platform-independentstrong dependenciesPlatform

dynamicallystaticallyBinding

distributed controlcentral controlControl of process logic

data-centric, self contained messages

navigate through complex object trees

Interaction pattern

weakstrongType system

common basic typescommon complex typesData model

asynchronoussynchronousCommunication style

intermediatorpoint-to-pointPhysical

Loose couplingTight coupling

30ICT

SOA reference models

4-16

31ICT

Basic service-oriented model

Service providerProvides software applications for specific needs as services.

Service requesterA requester could be a human user/application program/another service accessing the service through a desktop or a wireless browser; it could be an application program.

Service broker:A service broker provides a searchable repository of service descriptions.Examples of service brokers are UDDI (Universal Description, Discovery, and Integration).

32ICT

Extended service-oriented architecture

Composition

Description & Basic Operations

Mana-gement

•Capability•Inteface•Behavior•QoS

•Coordination•Conformance•Monitoring•QoS

•Publication•Discovery•Selection•Binding

Service provider

Service client

Service aggregator

performs

publishes

uses

Role actions

becomes

Operations•Assurance•Support

Market•Certification•Rating•SLAs

Service operator

Market maker

Managed services

Composite services

Basic services

Composition

Description & Basic Operations

Mana-gement

•Capability•Inteface•Behavior•QoS

•Coordination•Conformance•Monitoring•QoS

•Publication•Discovery•Selection•Binding

Service provider

Service client

Service aggregator

performs

publishes

uses

Role actions

becomes

Operations•Assurance•Support

Market•Certification•Rating•SLAs

Service operator

Market maker

Managed services

Composite services

Basic services

Papazoglou and GeorgakopoulosCACM,Oct. 2003

4-17

33ICT

OASIS Reference Model forService Oriented Architecture 1.0

OASIShttp://www.oasis-open.org/home/index.php

Abstract framework.Understanding significant entities and relationships between them within a service-oriented environment.Development of consistent standards or specifications supporting service-oriented environment.

Based on unifying concepts of SOA and may be used byarchitects developing specific service-oriented architecturesin training and explaining SOA.

Reference model not directly tied to any standards, technologies or other concrete implementation detailsProvide a common semantics that can be used unambiguously acrossand between different implementations. The reference model focuses on the field of software architecture.

34ICT

Scope of the reference model

4-18

35ICT

What is an SOA

Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.

Visibility, interaction, and effect are key concepts for describing the SOA paradigm.

Visibility refers to the capacity for those with needs and those with capabilities to be able to see each other.Whereas visibility introduces the possibilities for matching needs to capabilities (and vice versa), interaction is the activity of using a capability.The purpose of using a capability is to realize one or more real worldeffects. At its core, an interaction is “an act” as opposed to “an object”and the result of an interaction is an effect (or a set/series of effects).

36ICT

Principal concepts

4-19

37ICT

Principal concepts

Service: The means by which the needs of a consumer are brought together with the capabilities of a provider.

Visibility: The capacity for those with needs and those with capabilities to be able to interact with each other.

Service description: The information needed in order to use, or consider using, a service.

Execution context: The set of technical and business elements that form a path between those with needs and those with capabilities and that permit service providers and consumers to interact.

Interaction: The activity involved in making using of a capability offered, usually across an ownership boundary, in order to achieve a particular desired real-world effect.

Real world effect: The actual result of using a service, rather than merely the capability offered by a service provider.

Policy: A statement of obligations, constraints or other conditions of use of an owned entity as defined by a participant.

38ICT

Dynamics of services

4-20

39ICT

Dynamics of services

From a dynamic perspective, there are three fundamental concepts that are important in understanding what is involved in interacting with services: the visibility between service providers and consumers, the interaction between them, and the real world effect of interacting with a service.

40ICT

Visibility

4-21

41ICT

Visibility

For a service provider and consumer to interact with each other they have to be able to ‘see’ each other. Visibility is the relationship between service consumers and providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness and reachability.

Both the service provider and the service consumer MUST have information that would lead them to know of the other’s existence. Service awareness requires that the service description and policy – or at least a suitable subset thereof – be available.

Associated with all service interactions is intent – it is an intentional act to initiate and to participate in a service interaction. The extent of a service participant’s willingness to engage in service interactions may be the subject of policies.

Reachability is the relationship between service participants where they are able to interact; possibly by exchanging information. Reachability is an essential pre-requisite for service interaction – participants MUST be able to communicate with each other.

42ICT

Interacting with services

4-22

43ICT

Interacting with services

Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages. Key concepts that are important in understanding what it is involved in interacting with services revolve around the service description – which references a information model and a behavior model.

The formal descriptions of terms and the relationships between them (e.g., an ontology) provides a firm basis for selecting correct interpretations for elements of information exchanged.

The second key requirement for successful interactions with services is knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service.

Knowing the representation, structure, and form of information required is a key initial step in ensuring effective interactions with a service.

The information model of a service is a characterization of the information that may be exchanged with the service.

The process model characterizes the temporal relationships and temporal properties of actions and events associated with interacting with the service.

The action model of a service is the characterization of the actions that may be invoked against the service.

44ICT

Real world effect

4-23

45ICT

Real world effect

A real world effect can be the response to a request for information or the change in the state of some defined entities shared by the service participants.

In this context, the shared state does not necessarily refer to specific state variables being saved in physical storage but rather represents shared information about the affected entities. In addition, the internal actions that service providers and consumers perform as a result of participation in service interactions are, by definition, private and fundamentally unknowable. By unknowable we mean both that external parties cannot see others’ private actions and, furthermore, SHOULD NOT have explicit knowledge of them.

46ICT

Service description

4-24

47ICT

Service descriptionThe service description represents the information needed in order to use a service.

A service description SHOULD include sufficient data to enable a service consumer and service provider to interact with each other. This MAY include metadata such as the location of the service and what information protocols it supports and requires. It MAY also include dynamic information about the service, such as whether it is currently available.

A service description SHOULD unambiguously express the function(s) of the service and the real world effects that result from it being invoked.

A service description MAY include support for associating policies with a service and providing necessary information for prospective consumers to evaluate if a service will act in a manner consistent with the consumer’s constraints.

The service interface is the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real world effects as specified through the service functionality portion of the service description.

48ICT

Policies and contracts

4-25

49ICT

Policies and contractsA policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant. A contract, on the other hand, represents an agreement by two or more parties. Conceptually, there are three aspects of policies: the policy assertion, the policy owner (sometimes referred to as the policy subject) and policy enforcement.

Whereas a policy is associated with the point of view of individual participants, a contract represents an agreement between two or more participants. Like policies, contracts can cover a wide range of aspects of services: quality of service agreements, interface and choreography agreements and commercial agreements.

50ICT

Execution context

4-26

51ICT

Execution context

The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities.

52ICT

UML Profile and Metamodel for Services (UPMS)

4-27

53ICT

Metamodel – Overview

54ICT

Metamodel – Services (abstract syntax)

4-28

55ICT

UML profile – Services (abstract syntax)

56ICT

Example Scenario

OrderProcessing

4-29

57ICT

A Participant is a Component that provides and consumes services

58ICT

A Participant provides its capabilities through Services

The type of a Service specifies its capabilities and needs, and protocol for using them (if any)

4-30

59ICT

A Participant expresses its needs through Requisitions

Requisition needs are satisfied when connected to a Service with matching capabilities

60ICT

A Participant may implement its capabilities with ownedBehaviors

The processPurchaseOrderActivity is the method of the

processPurchaseOrderOperation

4-31

61ICT

A Service or Requisition may be typed by a simple Interface

Interfaces simply list the capabilities as

Operations, there is no protocol

62ICT

Or a Service or Requisition may be typedby a ServiceInterface

Service providedInterface

Service requiredInterface

behavior on theServiceInterface –protocol for usingthe capabilitites

Parts representingconsumers and

providers

4-32

63ICT

Participants may be assemblies of other Participants

Participant

Participant part

Service –capabilities typed

by ServiceInterface

Requisition –needs typed by ServiceInterface

64ICT

Message and RPC oriented styles for exchanging service data

4-33

65ICT

Contract for a Service

Fulfillment

Contract

66ICT

Choreographing Participants

4-34

67ICT

References

68ICT

References

[Atkinson and Kühne 2003] C. Atkinson and T. Kühne, "Model-Driven Development: A MetamodelingFoundation", IEEE Software, vol. 20, no. 5, pp. 36-41, 2003. http://www.mm.informatik.tu-darmstadt.de/staff/kuehne/publications/papers/mda-foundation.pdf

[Clark, et al. 2004] T. Clark, A. Evans, P. Sammut, and J. Willans, "Applied Metamodelling - A Foundation for Language Driven Development, Version 0.1", 2004. http://albini.xactium.com/web/index.php?option=com_remository&Itemid=54&func=select&id=1

[Seidewitz 2003] E. Seidewitz, "What Models Mean", IEEE Software, vol. 20, no. 5, pp. 26-32, 2003. [Swithinbank, et al. 2005] P. Swithinbank, M. Chessell, T. Gardner, C. Griffin, J. Man, H. Wylie, and L.

Yusuf, "Patterns: Model-Driven Development Using IBM Rational Software Architect", IBM, Redbooks, December 2005. http://www.redbooks.ibm.com/redbooks/pdfs/sg247105.pdf