SOS Concepts in DM2 – SoaML Example
• The purpose of this is to refine SOA concepts in DM2
– It is a summary for the DM2/SOA team
– Based on SoaML concepts but intended to represent SOA in
general – at the business and technical levels
– Not intended to fully introduce SoaML or DM2
• More SoaML info
– http://lib.modeldriven.org/MDLibrary/trunk/Pub/Presentations/SoaM
LBriefing.ppt
– www.soaml.org
• Note that there are 2 “styles” in SoaML, one “joint action”
focused and the other “interface” focused. We have tried to
bring these together in the logical model
– Joint action/collaboration style – more top down
– Provided and used interface style – more bottom up
May 2009
Page 1
Contents
• Some SoaML example models
• A logical SOA model supporting SoaML (Since SoaML is a UML
profile it doesn’t have a “clean” logical model)
• Example models mapped to logical model
– Not using IDEAS, but the styles are similar
• Parts of the DM2 model
May 2009
Page 2
Example scenario & models
This is the “joint action “/systems centric style
Marketplace Services
Order
Conformation
Provider
Consumer
What SOA represents at a high level
Shipped
Mechanics Are Us
Dealer
Consumer
Acme Industries
Manufacturer
Status
Ship Req
Shipped
Provider
Physical
Delivery
Consumer
Provider
Delivered
GetItThere Freight Shipper
May 2009
Page 4
Services Architecture for the Dealer Network
Dealer
Participant –
provides and
uses
services
Ship
Status
service
Purchasin
g service
Manufacturer
Participant –
provides and
uses
services
Shippin
g
service
A ServicesArchitecture (or SOA) is a network of participant roles providing and
consuming services to fulfill a purpose. The services architecture defines the
requirements for the types of participants and services that fulfill those roles.
In a services architecture – the participant roles are defined based on the
systems view – top down. The system defines the parts
May 2009
Page 5
Drilling down - Inside a Manufacturer
Order
Conformation
Production
Shipped
Fulfillment
Ship Req
Accounting
Shipped
Delivered
Acme Industries
Not every manufacturer is going to be the same inside – this shows some of the
internals of “Acme”
May 2009
Page 6
Architecture Inside of Acme
SOA architectures are able to “drill down” in more detail – this shows the
architecture inside of a particular manufacturer, Acme. Other
manufactures may have different internal architectures and processes.
May 2009
Page 7
Specifying Services
• Specification of services includes
– The roles each participant plays in the service, such as provider
and consumer
– The message types that go between the participants when the
service is enacted
– The interfaces provided and used by each participant for the
service
– The choreography of the interactions between the participants while
enacting the service
– Placeholders are provided for service policies and motivation
• Modeling services
– Services are modeled using “Service Contracts” and “Service
Interfaces” in SoaML. These use UML interfaces, classes and
behaviors.
May 2009
Page 8
High level view of a service
This view of a service only identifies the service name and the roles each
participant plays in the service. This is a high-level summary view.
May 2009
Page 9
Service Choreography for “Place Order”
The role of the consumer (a
participant that places orders)
and the consumers interface
The optional interaction to return
the quote
The role of the provider (an order
taker) and their interface
The optional interaction to
request a quote
The required interaction to place
an order
The required interaction to accept
or reject the order
A more detailed look at the same service. Note that this models a fully
asynchronous SOA – like most business interactions, the document
message types are detailed on the next page.
May 2009
Page 10
Message Detail for Place Order
This is the detail for the message types that correspond to the
interactions for the place order service.
Note that at the technology level this can produce XML schema for the
messages.
May 2009
Page 11
Linking messages to business information
SOA Messages can
reference and include
parts of the logical
information model –
forming a connection
between SOA and
enterprise data
May 2009
Page 12
Interfaces for Participants
Each role in the service that
receives interactions has an
interface, this is the
interface for a logical
technology component and
is implemented by
components providing or
using this service. This
service is bi-directional messages flow in both
directions.
Interfaces will correspond with parts of WSDL in a web services mapping of
SoaML
May 2009
Page 13
Logical System Components
Components
implement the
service interfaces
providing the link to
systems.
Participants and
services may be
used in multiple
architectures.
“Ports” on the participating
components provide and require the
service interfaces for each service
provided or used
May 2009
Page 14
Composite Application Components
Enterprise systems can be
integrated with adapter
components
This component is defined as a
composition of other
components.
Or, new implementation can be
defined inside of components.
Components can be assembled from other components by linking their
services. This corresponds to the architecture for Acme. Note that nested
components are USE OF an existing component
May 2009
Page 15
Compositions within compositions
This is the inside of the SAP AR component – also a composition, it uses
the existing SAP interfaces and adapts them to the enterprise contract.
This separates the concerns of a particular enterprise system from the
enterprise SOA. Sometimes the system interfaces are used directly or
adapted by an ESB.
May 2009
Page 16
Interface Centric Style in SoaML
Definition of a “Service Interface”
Interface
of
consume
r (if any)
Interface
of
provider
Definitio
n of
service
May 2009
Page 18
Service Interfaces and Ports
ServiceInterface
is the “type” of a
“RequestPoint” to
use service
ServiceInterface
is the “type” of a
“ServicePoint” to
provide service
Participants
provide and use
services via ports
May 2009
Page 19
Components are “used” in structured classes and
the ports connected to define composites
This is a
composite
Use of
component
defined
elsewhere that
provides a
service
Definition and use are separate – allows for reusable components
In a composition the composite is defined in terms of the use of pre-defined “parts”
Contrast with services (more top down) services architecture
May 2009
Page 20
Simple case – simple interface
• A simple (UML) interface can also be used to define a simple
service – this interface can be the type of a ServicePoint or
RequestPoint
May 2009
Page 21
Logical SOA model
As a profile SoaML does not have a logical meta model (it is built from UML).
This is a logical model, an interpretation of the concepts
Concept of “Joint Action” (or interface)
May 2009
Page 23
Concept of a services architecture or composite
May 2009
Page 24
Abstract Concept of a “System”
Used as a basic for the other models
May 2009
Page 25
Behavior As a System
May 2009
Page 26
Relating the logical models to the examples
Services Architecture
Services
Architecture
Participant
Role
Service
Channel
Connection
Service
Channel
Connection
May 2009
Page 28
Composite Application Components
Request
(Port)
Generalization
Participant
Participant
Role
Service
Channel
Service
(Port)
Connection
May 2009
Page 29
Service Choreography for “Place Order”
Provider
(Service Interface)
(Interactive Role)
Consumer
(Service Interface)
(Interactive Role)
outflow
Service
Contract
(Joint Action)
Information
Resource
inflow
Resource
Flow
ownership
inflow
May 2009
Page 30
Service Interfaces and Ports
Consumer
(Service Interface)
(Interactive Role)
Provider
(Service Interface)
(Interactive Role)
Service
Contract
(Joint Action)
Participant
Request
(Port)
Service
(Port)
May 2009
Page 31
Simple interfaces
Provider
(Service Interface)
(Interactive Role)
Consumer and service contract
implied
May 2009
Page 32
Applicable DM2 models
DM2_090827
IDEAS Serv ices
Services
IndividualResourceStateType
Resource
DispositionalProperty
propertyOfType
Capability
typeInstance
Performer
capabilityOfPerformer
resourceTypeInstanceOfMeasure
IndividualType
Condition
IndividualType
typeInstance
conditionTypeInstanceOfMeasure
Measure
WholePartType
overlapType
portPartOfPerformer
serv iceEnablesAccessTo
+
numericValue: string
overlapType
ruleConstraintOfActiv ityValidUnderCondition
Port
Service
Information
tuple
description
+
exemplarText: String
thingBeingDescribed
ServicePort
describedBy
ServiceDescription
overlapType
activ ityResourceOv erlap
typeInstance
activityResourceOverlapTypeInstanceOfRule
Guidance
Rule
overlapType
ruleConstrainsActiv ity
IndividualType
Activity
producer
consumer
overlapType
produces
activityPerformedByPerformerTypeInstanceOfRule
typeInstance
consumes
activityResourceOverlapTypeInstanceOfMeasure
overlapType
serv iceChannel
overlapType
typeInstance
activityPerformedByPerformerTypeInstanceOfMeasure
activ ityPerformedByPerformer
May 2009
Page 34
S Performer
WORKING DRAFT
IndividualType
Indiv idualResourceStateType
TupleType
Performer
ov erlapType
partType
Resource
IndividualType wholeType
activ ityPerforme
WholePartType
indiv idualResourceInLocationType
LocationType
activityPerformedByPerformerTypeInstanceOfRule
activ ityPerformableUnderCondition
Performer
A functionally,
physically,
and/or
behav iorally
related group of
regularly
interacting or
interdependent
elements.
IndividualType
Condition
PerformerCapableOfResponsibility
typeInstance
activityPerformedByPerformerTypeInstanceOfMeasure
IndividualType
Activity
IndividualResource
Indiv idualPerformer
System
WholePartType
Guidance
materialPartOfPerformer
Rule
OrganizationType
Service
typeInstance
Materiel
WholePartType
activityPerformableUnderConditionTypeInstanceOfMeasure
ruleConstrainsActiv ity
personTypePartOfPerformer
Organization
typeInstance
conditionTypeInstanceOfMeasure
When a Person Type is part of
another Person Type, that refers
to a role within a Person Type.
PersonType
IndividualType
Measure
+
DispositionalProperty
Skill
numericValue: string
propertyOfType
skillOfPersonType
WORKING DRAFT
May 2009
Page 35
IDEAS Resource Flow
Resource Flow
overlapType
activ ityPerformedByPerformer
overlapType
Note the
Activ ity that
does the
producing is
typically
different from
the consuming
activ ity
typeInstance
i.e., Role
activityPerformedByPerformerTypeInstanceOfRule
activityPerformedByPerformerTypeInstanceOfMeasure
IndividualType
Measure
Guidance
+
numericValue: string
Rule
WholePartType
typeInstance
indiv idualResourceInLocationType
resourceTypeInstanceOfMeasure
IndividualResourceStateType
IndividualType
Resource
Activity
typeInstance
Materiel
activityResourceOverlapTypeInstanceOfRule
consumer
producer
typeInstance
IndividualResourceState
activityResourceOverlapTypeInstanceOfMeasure
IndividualResource
overlapType
Location
IndividualPerformer
activ ityResourceOv erlap
GeoPoliticalExtent
overlapType
Information
activ ityPerformableUnderCondition
+
IndividualType
Organization
exemplarText: String
Data
Condition
May 2009
Page 36
IDEAS Activ ity
overlapType
activ ityResourceOv erlap
IndividualType
Measure
typeInstance
producer
consumer
IndividualType
+
conditionTypeInstanceOfMeasure
numericValue: string
Condition
typeInstance
activityResourceOverlapTypeInstanceOfMeasure
typeInstance
activityResourceOverlapTypeInstanceOfRule
IndividualType
Activity
typeInstance
overlapType
activityPerformableUnderConditionTypeInstanceOfMeasure
activ ityPerformableUnderCondition
overlapType
Activity
ruleConstraintOfActiv ityValidUnderCondition
typeInstance
WholePartType
activityPartOfCapabilityTypeInstanceOfMeasure
activ ityPartOfCapability
DispositionalProperty
Capability
typeInstance
activityChangesResourceTypeInstanceOfMeasure
BeforeAfterType
activ ityChangesResource
IndividualResourceStateType
Resource
overlapType
activ ityPerformedByPerformer
Performer
typeInstance
resourceTypeInstanceOfMeasure
typeInstance
activityPerformedByPerformerTypeInstanceOfMeasure
Guidance
overlapType
Rule
activ ityPerformedByPerformerTypeInstanceOfRule
overlapType
ruleConstrainsActiv ity
May 2009
Page 37
Suggested path
• Review examples and logical model
• See how examples would be rendered in DM2 today
• Compare with logical model, Resolve issues
May 2009
Page 38