Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
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