Model Driven Service Oriented Architecture using ModelPro and SoaML

jetmorebrisketSoftware and s/w Development

Aug 15, 2012 (5 years and 2 months ago)

401 views

Model Driven Service Oriented
Architecture

using

ModelPro and SoaML

Cory Casanave, CEO

Model Driven Solutions

Application

Deploy

JBI/Netbeans Platform & Tools

Manual

JBI/Netbeans

Application

Artifacts

ModelPro

Open Source MDA Tools

Relating the Parts

ModelPro

Provisioning

Engine

Uses

SoaML Cartridge

for

Netbeans & JBI

Provisioning Profile

Automates

Automated

JBI/Netbeans

Application

Artifacts

UML Tool

Provisioning Model

Users SOA

Model

Uses

OMG SoaML

UML Profile

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

Status: The SoaML specification is complete and is expected
to be recommended for adoption during the OMG meeting,
December 2008

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


ModelPro


ModelPro includes


A general purpose framework and tool for implementing Model Driven
Architecture (MDA) provisioning. ModelPro is designed for going from
business focused models to useful technical and business artifacts.


ModelPro can deal with a number of modeling profiles and meta models
as “input”. User models for various perspectives are structured for
provisioning based on one or more of these profiles or meta models.


ModelPro can deal with a variety of technology as a “provisioning
target”, automating the production of a majority of the platform artifacts
from models


A “Cartridge” provides the specification for how to provision a particular
profile or meta model to a particular technology target using ModelPro.


SoaML Cartridge Targeted to Java and Web Services is our first
cartridge


ModelPro is open source under GPL (Other licenses are available)

Business Concerns


Goals

Policy

Customers

Costs

Agility


Technology Specification

JMS, JEE, Web Services, JBI

WSDL, BPEL, XML Schema

Logical System Model

Technology Services (t
-
SOA),
Components

Interfaces, Messages & Data

Business Focused SOA Using Model Driven Architecture

Business Model

Enterprise Services (e
-
SOA)

Roles, Collaborations & Interactions

Process & Information

Refinement & Automation

Line
-
Of
-
Sight

Computation

Independent

Model

Platform

Independent

Model

Platform

Specific

Model

MDA

Terms

Incorporating Legacy Analysis

Value derived from the architecture

Business Concerns
Goals
Policy
Customers
Costs
Technology Specification
Web Services
WSDL, BPEL, XML Schema
Technology Specification
Web Services
WSDL, BPEL, XML Schema
Logical System Model
Technology Services (t
-
SOA),
Components
Interfaces, Messages & Data
Logical System Model
Technology Services (t
-
SOA),
Components
Interfaces, Messages & Data
One GSA Business Model
Business Services (b
-
SOA)
Roles, Collaborations & Interactions
Process & Information
One GSA Business Model
Business Services (b
-
SOA)
Roles, Collaborations & Interactions
Process & Information
Component

Acquisition

Specification

Web Services

Test &

Simulation

OMB 300

FEA/FTF

BRM

SRM

DRM*

Business Driven Technology

Facilitating Business Processes

Adapters

Components

Data

Deployment

Focus on the Business Model

Business Concerns




Technology Specification

JEE, JMS, Web Services

WSDL, BPEL, XML Schema

Logical System Model

Technology Services (t
-
SOA),
Components

Interfaces, Messages & Data

Business Model

Business Services (e
-
SOA)

Roles, Collaborations & Interactions

Process & Information

SOA Marketplace Example

Order

Conformation

Ship Req

Shipped

Shipped

Physical

Delivery

Delivered

Status

GetItThere Freight Shipper

Mechanics Are Us

Dealer

Acme Industries

Manufacturer

Marketplace Services

Order

Conformation

Ship Req

Shipped

Shipped

Physical

Delivery

Delivered

Status

Provider

Consumer

Provider

Consumer

Consumer

Provider

GetItThere Freight Shipper

Mechanics Are Us

Dealer

Acme Industries

Manufacturer

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.

Shippin
g
service

Ship
Status
service

Purchasin
g service

Participants

Participant

Participant

Participants represent logical or real people, systems or organizational units that
participate in services architectures and/or business processes. In SoaML
participants provide and use services, defining their external contract

Participants with ServicePoint and
RequestPoint

Participant

Participant

ServicePoint


point
where the manufacturer
offers the purchasing
service

RequestPoint


point
where the dealer uses the
purchasing service

Inside the Manufacturer

Order

Conformation

Shipped

Ship Req

Shipped

Delivered

Order Processing

Accounting

Service

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.



Service Contract

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.


Simple Protocol Choreography for Ordering
Service Contract

Message detail


references
message types

Services Interfaces

The service contract specifies the details of the service


what information,
assets and responsibilities are exchanged and under what rules.

Service Interfaces relate directly to WSDL

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

type

type

Message

Type

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

type

type

Real Example
-

Financial Management Enterprise
Context

External enterprise
level participants


The service
-
oriented business
architecture of an enterprise is
modeled as a
Collaboration

of
enterprise
-
level
Participants
.

This is the
use of

A service contract

specification

Our Focus

Note: Since this was done earlier, there are minor syntactic differences from the current SoaML profile

Inside Financial Management

Service representing
delegated responsibility for
interaction with an external
participant.

Service representing
interaction with another
participant within
Financial Management.

Roles of
participants inside
of finance

A Composite Service Contract

Financial Management is
responsible for providing a
number of Acquisition
Accounting services.

Process Activities Inside a Participant
(Outside of SoaML)


Workflow can be modeled
using
UML Activities.

Received event

Activity

Sent event

Information flow

Record Unfilled Customer Order Behavior

Control flow


Ultimately, behavior can be
specified using basic
UML
Activity Diagrams.

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.

Attributes

specify
descriptive information
having simple types.

Entities may be
described as having
a unique
identity
.

A relation between terms is
described by an
association

between classes.

A class may be
specialized

into sub
-
classifications.

An un
-
shaded class is
not detailed on this
diagram.

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
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

Business Concerns




Producing the logical systems model

Technology Specification

Web Services, JBI

WSDL, BPEL, XML Schema

Logical System Model

Technology Services (t
-
SOA),
Components

Interfaces, Messages & Data

Business Model

Business Services (b
-
SOA)

Roles, Collaborations & Interactions

Process & Information

Participants may be assemblies of other
Participants


representing system conponents

Participant

Participant part

ServicePoint


capabilities

typed by
ServiceInterface

RequestPoint


needs

typed by
ServiceInterface

Receivables Accounting Component Architecture

User of a consumed
service by multiple
internal parts.

Application Framework

Custom Business Logic Components

Generated Component

Wrapper

Custom Code

Framework

Component

Application components provide

service implementations

with user supplied logic.

These “plug into” the users

architecture as composite

application components

Framework components
add infrastructural
capabilities by extending
the platform (E.G. JBI)
and are called by the
provisioned code or
platform configuration

XSLT

Java

Etc.

As ModelPro progresses, there will be less and less need
for custom components, but the capability will remain.

Custom
part is
separate
from the
generated
part

Business Concerns




Technology Architecture

Technology Specification

JEE, JMS, Web Services, JBI

WSDL, BPEL, XML Schema

Logical System Model

Technology Services (t
-
SOA),
Components

Interfaces, Messages & Data

Business Model

Business Services (b
-
SOA)

Roles, Collaborations & Interactions

Process & Information

ModelPro/SoaML Demo

Provisioning SoaML

To

JBI, Web Services & Netbeans


Wen Zhu, MDS

Status Note

ModelPro & SoaML have been used internally and are now
being prepared for open source release early next year.


Also note that the demo model is not the same as has been
presented.

ModelDriven.org Business Model


Open source MDA Assets


Tools


Executable Application & Enterprise Models with Implementations


Open MDA Community
-

Vendor Independent


Platform Configurations


Services


Current


MDA/SOA Customer Projects leveraging Open Source


Funded Open Source Development


Future


Commercial, supported versions


Sponsorships & Commercial Licensing


Training & Support


Advertising and/or sales of commercial products on ModelDriven.org




Backup Slides


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>


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>




Provisioning of service components

<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.

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);

}


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>

<Organization__Schema


identity=”http://ocfo.gsa.gov/fmea/organization/1”>


<Organization>



<approved>true</approved>






</Organization>

</Party__Schema>


End result


this executes

Service representing
delegated responsibility for
interaction with an external
participant.

Service representing
interaction with another
participant within
Financial Management.

Roles of
participants inside
of finance

On this infrastructure

FAS
GSA SecureNet
/
MultiNet Financial Network
FMEA
Integration
Server
FMEA
Adapter
Server
FTP
Server
PBS
NEAR
TIRES
Adapter
IRIS
Adapter
Momentum
Adapter
JMS
TIRES
NEAR
AR
IRIS
STAR
Web
Service
Vehicle
Adapter
Finance
Users
Building
Data
Project
Data
Billing
Transactions
Vehicle
Master
STAR
Adapter
FMEA
Services
Server
Service
Service
FMEA
Service
Service
Service
Data
Manager
Work
Unit
FMEA
DBMS
Server
FMEA
Data
SQL Net
FMEA Presentation Server
Session
Management
Service
Service
FMEA
User
Interface
JMS
Https
:
Https Web Service
Pegasys
/
Momentum
Pegasys
/
Momentum
Fixed Assets
Module
Load
Balancer
SAML
SAML
FMS
SOA
JMS
Broker
Identity
Management
VPN
SOA
Web
Service
Adapters
Https
:
SAML
*
Any server may be clustered or combined
as required
Logs
VPN
JMS
Participant with Service Point

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.


Participant with Service Points and
Request Points

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.


Document and RPC Style service
operation parameters