Page 1 May 2009 SOS Concepts in DM2 – SoaML Example The purpose of this is to refine SOA concepts...
38
Page 1 May 2009 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 /SoaMLBriefing.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
-
Upload
meagan-hudson -
Category
Documents
-
view
213 -
download
0
Transcript of Page 1 May 2009 SOS Concepts in DM2 – SoaML Example The purpose of this is to refine SOA concepts...
Page 1May 2009
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/SoaMLBriefin
g.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
Page 2May 2009
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
Example scenario & models
This is the “joint action “/systems centric style
Page 4May 2009
Marketplace Services
Order
Conformation
Ship Req
Shipped
Shipped
PhysicalDelivery
Delivered
Status
Provider
Consumer
ProviderC
onsu
mer
Consumer
Provider
GetItThere Freight Shipper
Mechanics Are UsDealer
Acme IndustriesManufacturer
What SOA represents at a high level
Page 5May 2009
Services Architecture for the Dealer Network
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.
Shipping
service
Ship Status service
Purchasing service Manufacturer
Participant – provides and
uses services
Dealer Participant – provides and
uses services
In a services architecture – the participant roles are defined based on the systems view – top down. The system defines the parts
Page 6May 2009
Drilling down - Inside a Manufacturer
Order
Conformation
Shipped
Ship Req
Shipped
Delivered
Fulfillment
Production
Accounting
Acme Industries
Not every manufacturer is going to be the same inside – this shows some of the internals of “Acme”
Page 7May 2009
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.
Page 8May 2009
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.
Page 9May 2009
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.
Page 10May 2009
Service Choreography for “Place Order”
The role of the consumer (a participant that places orders) and the consumers interface
The role of the consumer (a participant that places orders) and the consumers interface
The role of the provider (an order taker) and their interface
The role of the provider (an order taker) and their interface
The optional interaction to request a quote
The optional interaction to request a quoteThe optional interaction to
return the quoteThe optional interaction to
return the quote
The required interaction to place an order
The required interaction to place an order
The required interaction to accept or reject the 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.
Page 11May 2009
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.
Page 12May 2009
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
Page 13May 2009
Interfaces for ParticipantsEach 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
Page 14May 2009
Logical System ComponentsComponents 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
“Ports” on the participating components provide and require the service interfaces for each service
provided or used
Page 15May 2009
Composite Application 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
Enterprise systems can be integrated with adapter
components
Enterprise systems can be integrated with adapter
components
Or, new implementation can be defined inside of
components.
Or, new implementation can be defined inside of
components.
This component is defined as a composition of other
components.
This component is defined as a composition of other
components.
Page 16May 2009
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.
Interface Centric Style in SoaML
Page 18May 2009
Definition of a “Service Interface”
Interface of
provider
Interface of
consumer (if any)
Definition of
service
Page 19May 2009
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
Page 20May 2009
Components are “used” in structured classes and the ports connected to define composites
Use of component
defined elsewhere that
provides a service
This is a composite
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
Page 21May 2009
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
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
Page 23May 2009
Concept of “Joint Action” (or interface)
Page 24May 2009
Concept of a services architecture or composite
Page 25May 2009
Abstract Concept of a “System”
Used as a basic for the other models
Page 26May 2009
Behavior As a System
Relating the logical models to the examples
Page 28May 2009
Services Architecture
Services Architecture
Participant Role
Service Channel
Connection
ConnectionService Channel
Page 29May 2009
Composite Application Components
Participant
Participant Role
Service Channel
Connection
Service(Port)
Request(Port)
Generalization
Page 30May 2009
Service Choreography for “Place Order”
Consumer(Service Interface)(Interactive Role)
Provider(Service Interface)(Interactive Role)
Resource Flow
inflow
Information Resource
outflow
inflowownership
Service Contract
(Joint Action)
Page 31May 2009
Service Interfaces and Ports
Service(Port)
Participant
Service Contract
(Joint Action)
Consumer(Service Interface)(Interactive Role)
Provider(Service Interface)(Interactive Role)
Request(Port)
Page 32May 2009
Simple interfaces
Provider(Service Interface)(Interactive Role)
Consumer and service contract implied
Applicable DM2 models
DM2_090827
Page 34May 2009
IDEAS Serv ices
IndividualType
Condition
IndividualType
Activity
IndividualType
Measure
+ numericValue: string
Performer
ServiceDescription
Port
overlapType
serv iceChannel
ServicePorttuple
describedBy
overlapType
ruleConstrainsActiv ity
Guidance
Rule
WholePartType
portPartOfPerformer
overlapType
ruleConstraintOfActiv ityValidUnderCondition
Service
overlapType
activ ityPerformedByPerformer
overlapType
activ ityResourceOv erlap
DispositionalProperty
CapabilitypropertyOfType
capabilityOfPerformer
overlapType
serv iceEnablesAccessTo
Information
+ exemplarText: String
IndividualResourceStateType
Resource
typeInstanceconditionTypeInstanceOfMeasure
typeInstanceresourceTypeInstanceOfMeasure
typeInstanceactivityResourceOverlapTypeInstanceOfRule
typeInstanceactivityResourceOverlapTypeInstanceOfMeasure
typeInstanceactivityPerformedByPerformerTypeInstanceOfMeasure
overlapTypeactivityPerformedByPerformerTypeInstanceOfRule
Services
description thingBeingDescribed
consumes
produces
producer
consumer
Page 35May 2009
IDEAS Performer
PersonType
System
OrganizationType
DispositionalProperty
Skill
Materiel
IndividualType
Activity
Performer
Guidance
Rule
WORKING DRAFT
Performer
A functionally, physically, and/or behav iorally related group of regularly interacting or interdependent elements.
activ ityPerformedByPerformer
WholePartType
personTypePartOfPerformer
WholePartType
materialPartOfPerformer
propertyOfType
skillOfPersonType
Organization
ruleConstrainsActiv ity
IndividualType
Measure
+ numericValue: string
IndividualType
Condition
activ ityPerformableUnderCondition
Service
WORKING DRAFT
IndividualResource
Indiv idualPerformer
activityPerformedByPerformerTypeInstanceOfRule
typeInstanceconditionTypeInstanceOfMeasure
typeInstanceactivityPerformedByPerformerTypeInstanceOfMeasure
typeInstanceactivityPerformableUnderConditionTypeInstanceOfMeasure
WholePartType
indiv idualResourceInLocationTypeIndividualType
LocationType
When a Person Type is part of another Person Type, that refers to a role within a Person Type.
PerformerCapableOfResponsibility
Resource
TupleType
overlapType
IndividualType
Indiv idualResourceStateType
wholeType
partType
Page 36May 2009
IDEAS Resource Flow
IndividualResourceStateType
Resource
Data
Materiel
IndividualType
Activity
IndividualType
Measure
+ numericValue: string
overlapType
activ ityResourceOverlap
Guidance
Rule
overlapType
activ ityPerformedByPerformer
Location
GeoPoliticalExtent
Note the Activ ity that does the producing is typically different from the consumingactiv ity
i.e., Role
Information
+ exemplarText: String
IndividualResourceState
IndividualResource
Organization
IndividualPerformer
Resource Flow
typeInstanceactivityPerformedByPerformerTypeInstanceOfMeasure
overlapTypeactivityPerformedByPerformerTypeInstanceOfRule
typeInstanceactivityResourceOverlapTypeInstanceOfRule
typeInstanceactivityResourceOverlapTypeInstanceOfMeasure
typeInstanceresourceTypeInstanceOfMeasure
IndividualType
Condition
overlapType
activ ityPerformableUnderCondition
WholePartType
indiv idualResourceInLocationType
producerconsumer
Page 37May 2009
IDEAS Activ ity
IndividualType
Activity
Performer
Guidance
Rule
overlapType
activ ityPerformedByPerformer
typeInstanceactivityPerformedByPerformerTypeInstanceOfMeasure
overlapType
ruleConstrainsActiv ity
IndividualType
Measure
+ numericValue: stringIndividualType
Condition
overlapType
activ ityPerformableUnderCondition
Activity
IndividualResourceStateType
Resource
DispositionalProperty
Capability
WholePartType
activ ityPartOfCapability
BeforeAfterType
activ ityChangesResource
overlapType
ruleConstraintOfActiv ityValidUnderCondition
overlapType
activ ityResourceOverlap
typeInstanceactivityPerformableUnderConditionTypeInstanceOfMeasure
typeInstanceactivityResourceOverlapTypeInstanceOfMeasure
typeInstanceactivityResourceOverlapTypeInstanceOfRule
typeInstanceconditionTypeInstanceOfMeasure
overlapType
activ ityPerformedByPerformerTypeInstanceOfRule
typeInstanceresourceTypeInstanceOfMeasure
typeInstanceactivityPartOfCapabilityTypeInstanceOfMeasure
typeInstanceactivityChangesResourceTypeInstanceOfMeasure
producerconsumer
Page 38May 2009
Suggested path
• Review examples and logical model
• See how examples would be rendered in DM2 today
• Compare with logical model, Resolve issues
