soa sig presentation/demonstration Øystein haugen/arne j. berre, sintef,
DESCRIPTION
OMG SoaML Service oriented architecture Modeling Language - UML Profile and Metamodel for Services. SOA SIG presentation/demonstration Øystein Haugen/Arne J. Berre, SINTEF, Jim Amsden, IBM, Cory Casanave, ModelDriven Solutions. Submitters 88Solutions Adaptive EDS Model Driven Solutions - PowerPoint PPT PresentationTRANSCRIPT
OMG11/04/2008
OMG SoaMLService oriented architecture Modeling Language
- UML Profile and Metamodel for Services
SOA SIG presentation/demonstrationØystein Haugen/Arne J. Berre, SINTEF,
Jim Amsden, IBM, Cory Casanave, ModelDriven Solutions
SoaML Specification – Revised UPMS Submission
Object Management Group
The SoaML submission team
Submitters
– 88Solutions
– Adaptive
– EDS
– Model Driven Solutions
– Capgemini
– Fujitsu
– Fundacion European Software Institute
– Hewlett-Packard
– International Business Machines
– MEGA International
– MID GmbH
– Rhysome
– Softeam
– Telelogic AB
Supporters
– Everware-CBDI
– General Services Administration
– VisumPoint
– Mega
– BAE Systems
– DERI – University of Innsbruck
– DFKI
– France Telecom R&D
– NKUA – University of Athens
– Oslo Software
– SINTEF
– THALES Group
– University of Augsburg
– Wilton Consulting Group
SoaML Specification – Revised UPMS Submission
Object Management Group
SoaML Goals
Intuitive and complete support for modeling services in UML
Support for bi-directional asynchronous services between multiple parties
Support for Services Architectures where parties provide and use multiple services.
Support for services defined to contain other services
Easily mapped to and made part of a business process specification
Compatibility with UML, BPDM and BPMN for business processes
Direct mapping to web services
Top-down, bottom up or meet-in-the-middle modeling
Design by contract or dynamic adaptation of services
To specify and relate the service capability and its contract
No changes to UML
SoaML Specification – Revised UPMS Submission
Object Management Group
Service
Service is defined as an offer of value to another party, enabled by one or more capabilities.
Here, the access to the service is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service contract. A service is provided by a participant acting as the provider of the service—for use by others. The eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider. [OASIS RM]
SoaML Specification – Revised UPMS Submission
Object Management Group
Business Concerns
Goals
Policy
Customers
Costs
Agility
Technology SpecificationJMS, JEE, Web Services
WSDL, BPEL, XML Schema
Technology SpecificationJMS, JEE, Web Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
Business Focused SOA Using Model Driven Architecture
Business ModelEnterprise Services (e-SOA)
Roles, Collaborations & InteractionsProcess & Information
Business ModelEnterprise Services (e-SOA)
Roles, Collaborations & InteractionsProcess & Information
Refin
emen
t & A
uto
matio
n
Lin
e-Of-S
igh
tC
om
pu
tati
on
Ind
epen
den
tM
od
el
Pla
tfo
rmIn
dep
end
ent
Mo
del
Pla
tfo
rmS
pec
ific
Mo
del
MDATerms
SoaML Specification – Revised UPMS Submission
Object Management Group
Incorporating Legacy Analysis
SoaML Specification – Revised UPMS Submission
Object Management Group
Value derived from the architecture
Business Concerns
Goals
Policy
Customers
Costs
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Technology SpecificationWeb Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t -SOA),
ComponentsInterfaces, Messages & Data
Logical System ModelTechnology Services (t -SOA),
ComponentsInterfaces, Messages & Data
One GSA Business ModelBusiness Services (b -SOA)
Roles, Collaborations & InteractionsProcess & Information
One GSA Business ModelBusiness Services (b -SOA)
Roles, Collaborations & InteractionsProcess & Information
ComponentAcquisition Specification
Web Services
Test &SimulationOMB 300
FEA/FTFBRMSRMDRM*
Business Driven Technology
Facilitating Business Processes
Adapters
Components
DataDeployment
SoaML Specification – Revised UPMS Submission
Object Management Group
Focus on the Business Model
Business Concerns
Technology SpecificationJEE, JMS, Web Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
Business ModelBusiness Services (e-SOA)
Roles, Collaborations & InteractionsProcess & Information
SoaML Specification – Revised UPMS Submission
Object Management Group
SOA Marketplace Example
Order
Conformation
Ship Req
Shipped
Shipped
PhysicalDelivery
Delivered
Status
GetItThere Freight Shipper
Mechanics Are UsDealer
Acme IndustriesManufacturer
SoaML Specification – Revised UPMS Submission
Object Management Group
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
SoaML Specification – Revised UPMS Submission
Object Management Group
Services Architecture
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 service realizations that fulfill those roles.
The services architecture puts a set of services in context and shows how participants work together for a community or organization without required process management.A community ServicesArchitecture is defined using a UML Collaboration.
Shipping
service
Ship Status service
Purchasing service
SoaML Specification – Revised UPMS Submission
Object Management Group
Inside the Manufacturer
Order
Conformation
Shipped
Ship Req
Shipped
Delivered
Order Processing
Accounting
Service
SoaML Specification – Revised UPMS Submission
Object Management Group
Services architecture for a participant
ParticipantArchitecture is the high-level services architecture of a participant that defines how a set of internal and external participants use services to implement the responsibilities of the participant. A participant will also frequently have a business process.
SoaML Specification – Revised UPMS Submission
Object Management Group
Participants
ParticipantParticipant
Participants represent logical or real people or organizational units that participate in services architectures and/or business processes. In SoaML
participants provide and use services, defining their external contract
SoaML Specification – Revised UPMS Submission
Object Management Group
Participants with ServicePoint and RequestPoint
ParticipantParticipant
ServicePoint – point where the manufacturer
offers the purchasing service
RequestPoint – point where the dealer uses the purchasing service
SoaML Specification – Revised UPMS Submission
Object Management Group
ServiceContract
A ServiceContract defines the terms, conditions, interfaces and choreography that interacting participants must agree to (directly or indirectly) for the service to be enacted - the full specification of a service which includes all the information, choreography and any other “terms and conditions” of the service. A ServiceContract is binding on both the providers and consumers of that service. The basis of the service contract is also a UML collaboration that is focused on the interactions involved in providing a service. A participant plays a role in the larger scope of a ServicesArchitecture and also plays a role as the provider or user of services specified by ServiceContracts.
SoaML Specification – Revised UPMS Submission
Object Management Group
Service Contract
The service contract specifies the details of the service – what information, assets and responsibilities are exchanged and under what rules
Role within service
Role within service
Service Contract
Service interface
corresponding to role
Service interface
corresponding to role
Information processed by
order processor
Information received by
orderer
typetype
SoaML Specification – Revised UPMS Submission
Object Management Group
Simple Protocol Choreography for Ordering Service Contract
SoaML Specification – Revised UPMS Submission
Object Management Group
Compound services
Compound Services are defined by using more granular services to “build up” an enterprise scale service
Each composed service becomes a port on the service interface
typetype
SoaML Specification – Revised UPMS Submission
Object Management Group
Real Example - Financial Management Enterprise Context
External enterprise level participants
External enterprise level participants
• The service-oriented business architecture of an enterprise is modeled as a Collaboration of enterprise-level Participants.
• The service-oriented business architecture of an enterprise is modeled as a Collaboration of enterprise-level Participants.
This is the use ofA service contract
specification
This is the use ofA service contract
specificationOur FocusOur Focus
SoaML Specification – Revised UPMS Submission
Object Management Group
Inside Financial ManagementService representing
delegated responsibility for interaction with an external
participant.
Service representing delegated responsibility for interaction with an external
participant.
Service representing interaction with another
participant within Financial Management.
Service representing interaction with another
participant within Financial Management.
Roles of participants inside
of finance
Roles of participants inside
of finance
SoaML Specification – Revised UPMS Submission
Object Management Group
A Composite Service Contract
Financial Management is responsible for providing a number of Acquisition
Accounting services.
Financial Management is responsible for providing a number of Acquisition
Accounting services.
SoaML Specification – Revised UPMS Submission
Object Management Group
Simple Bill Submission Service Contract• A service contract is modeled as a
UML Collaboration.
• The required conversation may be specified using an Owned Behavior (e.g., Interaction or Activity)
• A service contract is modeled as a UML Collaboration.
• The required conversation may be specified using an Owned Behavior (e.g., Interaction or Activity)
Indicates ownership
First the submitter submits a bill to the receiver…
First the submitter submits a bill to the receiver…
…then either the bill is successfully delivered or it is returned.
…then either the bill is successfully delivered or it is returned.
Note that, while one Participant requests the service and the other
responds, information may flow both ways during the interaction.
Note that, while one Participant requests the service and the other
responds, information may flow both ways during the interaction.
SoaML Specification – Revised UPMS Submission
Object Management Group
Process Activities Inside a Participant (Outside of SoaML)
• Workflow is modeled using UML Activities.
• Workflow is modeled using UML Activities.
Received eventReceived event
ActivityActivity Sent eventSent event
Information flowInformation flow
SoaML Specification – Revised UPMS Submission
Object Management Group
Record Unfilled Customer Order Behavior
Control flowControl flow
• Ultimately, behavior can be specified using basic UML Activity Diagrams.
• Ultimately, behavior can be specified using basic UML Activity Diagrams.
SoaML Specification – Revised UPMS Submission
Object Management Group
Information Model – For Messages and Entities
This means “zero or more”
This means “one or more”This indicates a compositional (as opposed to referential) association.
This is a constraint that defines the sub-classification.
A term in the vocabulary represents a class of things to be described.
A term in the vocabulary represents a class of things to be described.
Attributes specify descriptive information having simple types.
Attributes specify descriptive information having simple types.
Entities may be described as having a unique identity.
Entities may be described as having a unique identity.
A relation between terms is described by an association between classes.
A relation between terms is described by an association between classes.
A class may be specialized into sub-classifications.
A class may be specialized into sub-classifications.
An un-shaded class is not detailed on this diagram.
SoaML Specification – Revised UPMS Submission
Object Management Group
Integrating the Information Model with SOA
Business transaction Business transaction
The information model details the vocabulary of the business entities and transactions used in the process model.
The information model details the vocabulary of the business entities and transactions used in the process model.
The process model describes how business activities are (or are to be) carried out.
The process model describes how business activities are (or are to be) carried out.
State changes due to the activities
Workflow
Activities
Implicit memory of business information
SoaML Specification – Revised UPMS Submission
Object Management Group
Business Concerns
Technology Architecture
Technology SpecificationJEE, JMS, Web Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
One GSA/FMEA Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
SoaML Specification – Revised UPMS Submission
Object Management Group
Participants may be assemblies of other Participants
Participant
Participant part
ServicePoint – capabilities typed
by ServiceInterfaceRequestPoint – needs typed by ServiceInterface
SoaML Specification – Revised UPMS Submission
Object Management Group
Receivables Accounting Component Architecture
User of a consumed service by multiple internal parts.
User of a consumed service by multiple internal parts.
SoaML Specification – Revised UPMS Submission
Object Management Group
Business Concerns
Technology Architecture
Technology SpecificationJEE, JMS, Web Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
SoaML Specification – Revised UPMS Submission
Object Management Group
Example Web Services Generation
<wsdl:portType name=“BillSubmission.BillSubmissionReceiverInterface"> <wsdl:operation name=“submitBill"> <wsdl:input message="tns:BillSubmissionCluster“ name=“billSubmission"> </wsdl:input> </wsdl:operation> </wsdl:portType>
<wsdl:portType name=“BillSubmission.BillSubmissionSubmitterInterface"> <wsdl:operation name=“notifyBillDelivered"> <wsdl:input message="tns:BillDeliveredCluster“ name=“billDelivered"> </wsdl:input> </wsdl:operation> <wsdl:operation name=“notifyBillReturned"> <wsdl:input message="tns:BillReturnedCluster“ name=“billReturned"> </wsdl:input> </wsdl:operation> </wsdl:portType>
SoaML Specification – Revised UPMS Submission
Object Management Group
Example Transaction Message XML Document<BillSubmissionCluster>
<BusinessTransaction><transactionID> … </transactionID>
</BusinessTransaction><BillSubmission>
<bill><Bill>
<billID> … </billID><principleAmount> … </principleAmount>…
<payer><Party>
<partyID> … </customerID></Party>
</payer>…
<lineItems> … </lineItems>
</Bill> </bill>
<billingAddress><BillingAddressCluster>
<Address> … </Address><BillingAddress> … </BillingAddress>
</BillingAddressCluster><billingAddress>
</BillSubmission></BillSubmissionCluster>
<BillSubmissionCluster><BusinessTransaction>
<transactionID> … </transactionID></BusinessTransaction><BillSubmission>
<bill><Bill>
<billID> … </billID><principleAmount> … </principleAmount>…
<payer><Party>
<partyID> … </customerID></Party>
</payer>…
<lineItems> … </lineItems>
</Bill> </bill>
<billingAddress><BillingAddressCluster>
<Address> … </Address><BillingAddress> … </BillingAddress>
</BillingAddressCluster><billingAddress>
</BillSubmission></BillSubmissionCluster>
SoaML Specification – Revised UPMS Submission
Object Management Group
Implementation of service components
<<Prov ision>>
A ss et A cc ou n t i n g Ser v i ce s T ie r
{Language = "Java+XM L",
Technical Architecture = "JEE-Messaging" }
<<MessageDrivenBean>><<StatelessSessionBean>>
: Asset Lifecyc le Accounti ng Servi ces
<<XSLT Implementation>>
: Proper ty Data Manager
<<MessageDrivenBean>>
<<StatelessSessionBean>>
: Receivables Accounti ng
<<XSLT Implementation>>
: Proj ec t Data Manager
<<XSLT Implementat ion>>
: Party Data Manager
<provisioningContext name="service“…>
<projectRef folder="EjbClient"/>
<projectRef folder="AppClient"/>
<projectRef folder="Ejb"/>
<projectRef folder="ear"/>
<projectRef folder="JbossConfig"/>
</provisioningContext>
Note – stereotypes for provisioning are not part of SoaML – this shows one way to do it.
SoaML Specification – Revised UPMS Submission
Object Management Group< < S e rv i ce C o m p on e n t> >
A ss e t L i fe c y c l e A cc o u n t i n g S e r v i c e s
< < S e r v ic e C o m p o n e n t> >
: A s s et R e c o r d M a n ag e r
: A s se t D e p re c ia t i on C on su m e r
: A s se t T ra ck in g C o n su m er
: E xp en se A cc ru a l C o n su m e r
: G e n e ra l L e d g er P o s t in g C o n su m er
: R e ce iv ab l e E s ta b li sh m en t C on su m e r
< < S e r v ic e C o m p o n e n t> >
: A s s et P r o j e c t M a n a g e r
: A ss e t C o m pl et i o n E s ta b li sh m en t C on su m e r
: A ss et D isp o sa l N o t if ica t io n C on su m e r
< < D a ta C o m p o ne n t> >
: P r o p e r ty D a t a M a n a g er
< < D a ta C o m p o n e nt> >
: P ar ty D a ta M a n a g e r
< < D a ta C o m po n e n t> >
: Project Data Manager
: Asset Record Establishment Provider
: Asset Record Update Provider
: Asset Acquisition Notification Provider
: Asset Cost Accumulation Provider
: Asset Completion Establishment Provider
: Asset Ownership Establishment Provider
: Asset Valuation Notification Provider
: Asset Condition Notification Provider
: Asset Status Change Notification Provider
: Asset Transfer Notification Provider
: Asset Disposal Notification Provider
: Asset Record Query Provider
: Asset Project Establishment Provider
: Asset Project Update Provider
: Asset Project Status Notification Provider
: Asset Project Query Provider
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
<<delegate>>
Implementation of service components
public class Asset_Completion_Establishment_ConsumerAsset_Completion_Establishment_Provider_InterfaceInternal {
… …
static public Document establish_asset_completion(Document request) throws CheckedException {
……
return
gov.gsa.fmea.Asset_Record_Manager.
Asset_Completion_Establishment_ProviderAsset_Completion_Establishment_Provider_InterfaceInternal.
establish_asset_completion(request);
}
SoaML Specification – Revised UPMS Submission
Object Management Group
Mapping – Classes
<Party__Schema identity=”URI”><Party>
<party_id>ABC123<party_id><legal_address>
<Address><city>Vienna</city><state>VA</state>
</Address></legal_address><organizations>
<Organization__Item identity=”http://ocfo.gsa.gov/fmea/organization/1”/><Organization__Item identity=”…”/>…
</organizations></Party>
</Party__Schema>
<Party__Schema identity=”URI”><Party>
<party_id>ABC123<party_id><legal_address>
<Address><city>Vienna</city><state>VA</state>
</Address></legal_address><organizations>
<Organization__Item identity=”http://ocfo.gsa.gov/fmea/organization/1”/><Organization__Item identity=”…”/>…
</organizations></Party>
</Party__Schema>
<Organization__Schema identity=”http://ocfo.gsa.gov/fmea/organization/1”><Organization>
<approved>true</approved>…
</Organization></Party__Schema>
<Organization__Schema identity=”http://ocfo.gsa.gov/fmea/organization/1”><Organization>
<approved>true</approved>…
</Organization></Party__Schema>
SoaML Specification – Revised UPMS Submission
Object Management Group
End result – this executesService representing
delegated responsibility for interaction with an external
participant.
Service representing delegated responsibility for interaction with an external
participant.
Service representing interaction with another
participant within Financial Management.
Service representing interaction with another
participant within Financial Management.
Roles of participants inside
of finance
Roles of participants inside
of finance
SoaML Specification – Revised UPMS Submission
Object Management Group
On this infrastructure
FAS
GSA SecureNet /MultiNet Financial Network
FMEAIntegration
Server
FMEAAdapterServer
FTPServer
PBS
NEAR
TIRES Adapter
IRIS Adapter
Momentum Adapter
JMS
TIRES
NEAR AR
IRIS
STAR
WebService
Vehicle Adapter
FinanceUsers
BuildingData
ProjectData
BillingTransactions
VehicleMaster
STAR Adapter
FMEAServicesServer
ServiceServiceFMEA
Service
ServiceServiceDataManager
WorkUnit
FMEADBMSServer
FMEAData
SQL Net
FMEA Presentation Server
SessionManagement
ServiceServiceFMEA
UserInterface
JMS
Https:
Https Web Service
Pegasys /Momentum
Pegasys /Momentum
Fixed Assets Module
LoadBalancer
SAML
SAML
FMS
SOAJMS
Broker
IdentityManagement
VPN
SOAWeb
ServiceAdapters
Https :
SAML
* Any server may be clustered or combined as required
Logs
VPN
JMS
SoaML Specification – Revised UPMS Submission
Object Management Group
Modeling Services with Capabilities
Capabilities model the service contract combined with the capability to provide it
A network of capabilities helps to identify and define services
Capabilities can then be assigned to participants
SoaML Specification – Revised UPMS Submission
Object Management Group
ServicePoints and Service Participants
A ServicePoint is the offer of a service by one participant to others using well defined terms, conditions and interfaces. A ServicePoint defines the connection point through which a Participant offers its capabilities and provides a service to clients.A ServicePoint is a mechanism by which a provider Participant makes available services that meet the needs of consumer requests as defined by ServiceInterfaces, Interfaces and ServiceContracts. A ServicePoint is represented by a UML Port on a Participant stereotyped as a «ServicePoint», .
SoaML Specification – Revised UPMS Submission
Object Management Group
ServiceInterface
a ServiceInterface can be the type of a service port. The service interface has the additional feature that it can specify a bi-directional service – where both the provider and consumer have responsibilities to send and receive messages and events. The service interface is defined from the perspective of the service provider using three primary sections: the provided and required Interfaces, the ServiceInterface class and the protocol Behavior.
SoaML Specification – Revised UPMS Submission
Object Management Group
Participant with ServicePoint
A ServicePoint is the point of interaction on a Participant where a service. On a service provider this can be thought of as the “offer” of the service (based on the service interface). The ServicePoint is the point of interaction for engaging participants in a service via its service interfaces.
SoaML Specification – Revised UPMS Submission
Object Management Group
Participant with ServicePoints and RequestPoints
The type of a RequestPoint is also a ServiceInterface, or UML Interface, as it is with a Service point. The RequestPoint is the conjugate of a ServicePoint in that it defines the use of a service rather than its provision. This will allow us to connect service providers and consumers in a Participant.
SoaML Specification – Revised UPMS Submission
Object Management Group
Participants may be assemblies of other Participants
Participant
Participant part
ServicePoint – capabilities typed
by ServiceInterfaceRequestPoint – needs typed by ServiceInterface
SoaML Specification – Revised UPMS Submission
Object Management Group
Document and RPC Style service operation parameters
SoaML Specification – Revised UPMS Submission
Object Management Group
Agent and Milestones
Agent
– autonomous entity
– has its own lifecycle behavior
– can adapt to the environment
• also through modification of its definition
Milestone
– defines a value of progress
– attached to behavioral elements
– is used especially for dynamic analysis of behavior that does not necessarily end
SoaML Specification – Revised UPMS Submission
Object Management Group
Milestone
«Milestone» Order <1>
«Milestone» Order <0>
A Milestone is a means for depicting progress in behaviors in order to analyze liveness. Milestones are particularly useful for behaviors that are long lasting or even infinite.A Milestone can be understood as a “mythical” Signal. A mythical Signal is a conceptual signal that is sent from the behavior every time a point connected to the Milestone is passed during execution. The signal is sent to a conceptual observer outside the system that is able to record the origin of the signal, the signal itself and its progress value.
SoaML Specification – Revised UPMS Submission
Object Management Group
Business Motivation Model (BMM) integration
• Business requirements can be captured using the OMG Business Motivation Model (BMM).
• Any UML BehavioredClassifier including (for example a ServicesContract) may realize the BMM Motivation concept of motivation realization. This allows services models to be connected to the business motivation and strategy linking the services to the things that make them business relevant.
SoaML Specification – Revised UPMS Submission
Object Management Group
BMM with MeansRealizations
SoaML Specification – Revised UPMS Submission
Object Management Group
Relating to other standards
SoaML integration with BPMN 2.0 and BPDM will be related to the ongoing BPMN 2.0 standardization
Extensions for Agents and semantic services will also relate to semantics, ontologies and other OMG metamodels like ODM and SBVR
Limited BMM integration is included to tie services to the business